El elemento clear para las appSettings y los deployments.

Desde hace unos días, he estado hablando del tema de los deployments centrándome sobre todo en la herencia de los web.config de nuestras aplicaciones (funcionalidad muy interesante y a tener en cuenta en todo momento).

Hay varias formas de sobrescribir esta herencia o de configurar nuestro web.config para que nuestra aplicación trabaje de una forma u otra, y hoy vamos a ver otro mecanismo.

Este mecanismo, no viene a ser otro que el elemento clear de las appSettings.

El elemento clear, quita todas las referencias de los appSettings de nuestra aplicación, y solo nos permite trabajar con la configuración agregada por el elemento add.

Usarlo es muy fácil:

<appSettings>
<clear />
<add key=”NumberOfItems” value=”20” />
</appSettings>

Útil y fácil como tienen que ser las cosas, ahora amigos, os dejo. Pero os dejo acompañados del fabuloso Bobby Womack y su genial Across 110th Street, inmortalizada por el no menos fabuloso y genial Tarantino en los títulos de crédito de Jackie Brown.

Como conseguir que no haya herencia en los web.config. El tag location.

Aunque recientemente hablaba de la herencia de los web.config como algo bueno y que tenemos que tener en cuenta cuando desarrollamos aplicaciones que van a ser ejecutadas en directorios virtuales dentro de Web Sites, esta característica, también nos puede suponer que nos encontremos con algunos problemas.

Así, pues, de forma muy sencilla, podemos “desactivar” la herencia de web.config (o directamente no heredar) consiguiendo de esta forma que cada aplicación, este siendo hospedada por medio de un Web Site o un Virtual Directory, tenga su propia configuración completa.

El tag del web.config location, nos va a permitir deshabilitar esta herencia por medio del atributo inheritInChildApplications.

Para usarlo, tendríamos que poner dentro los nodos del web.config a los que vamos a hacerles el wrapper.

<location path="." inheritInChildApplications="false">
<connectionStrings>
...
</connectionStrings>
<system.web>
...
</system.web>
</location>

Espero que este código os resulte útil. Cualquier comentario será bienvenido.

 

La herencia de los Web.config, los deployment y el tag remove

Anteriormente, hemos visto, que es útil y una buena práctica, el soportar la herencia de los web.config de tus apliaciones web.

Puede ser muy útil, tener un web.config padre y una serie de web.config hijos, donde se encapsule la configuración de cada una de tus aplicaciones ya que así los deployment y mantenimientos son más sencillos y sobre todo, así mantienes todas tus aplicaciones de una forma más compacta.

Eso si, siempre se pueden dar casos, donde nos encontremos que nuestro web.config esta herendado de otro, y el web.config padre, hace referencia a elementos que nos necesitamos, lo cual nos va a generar un problema, pero tranquilos, esto es muy fácil solucionarlo gracias al tag remove.

El tag remove, se va a encargar de “eliminar” las referencias del web.config que no necesitemos.

Un ejemplo de su uso sería el siguiente:

<httpModules>
<remove name="HttpExceptionHandlerPipeline" />
<remove name="HttpsSwitcherPipeline" />
<remove name="RedirectModule" />
<add name="UrlRoutingModule" type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
</httpModules>

Sencillo y útil, como todo debería de ser.

La herencia de web.config y los deployment.

Es interesante ver como por norma general e independientemente del paso del tiempo, los deployment han sido y son tareas que sin tener porque, se complican y llegan a rayar lo absurdo.

Generalmente cuando estamos en un proyecto, disponemos de distintos entornos, conforme vamos avanzando en el ciclo de vida del desarrollo del software, vamos desplegando la aplicación en el entorno de desarrollo, preproducción etc. y en el momento que tenemos que poner la aplicación en producción siempre surge alguna cosa.

Si el proyecto en el que nos encontramos trabajando es muy grande, es una buena práctica partirlo en porciones más pequeñas, así podemos trabajar de una forma más desacoplada y posteriormente el deployment también podemos conseguir que sea más sencillo.

Supongamos que estamos en un proyecto que es muy grande, y que en este momento, estas desarrollando pequeñas piezas, que sin formar parte del core del negocio que intenta resolver, lo complementa.

Una buena solución es trabajar en distintas soluciones de manera que una funcionalidad x la tienes totalmente encapsulada en la solución que le corresponde. Y así, cuando llega el momento de hacer el deployment, puedes desplegar el core de tu negocio en un Web Site, y todas las aplicaciones satélites pueden ser virtual directories dentro de tu web site principal.

A la hora de hacer el deployment, cuando tenemos un Web Site que contiene n directorios virtuales, podemos observar como el web.config de los directorios virtuales, heredan del web.config del Web Site, de esta manera, puedes dejar toda la configuración común de tu app en el web.config de la aplicación que implementa el core de tu negocio, y toda la configuración de tus aplicaciones satélites en el web.config de cada una de ellas (en su respectivo virtual directory), así consigues tener la configuración de cada pieza aislada y más controlada.

Seguramente esta práctica, genera un trabajo de configuración y mantenimiento mayor, pero merece la pena por el hecho de tener todo más aislado y desacoplado.