JASoft.org

El blog de José Manuel Alarcón Aguín. Programación web y mucho más...

MENÚ - JASoft: JM Alarcón

ASP.NET: separando el web.config de nuestra aplicación en varios archivos

Imagen ornamental - icono de archivo .config El archivo web.config contiene toda la configuración de nuestras aplicaciones web basadas en .NET. En él se puede encontrar de todo: desde las cadenas de conexión a las bases de datos, hasta los detalles de cómo debe funcionar Internet Information Server, pasando por todo tipo de parámetros propios de la aplicación que hemos desarrollado.

A veces este archivo puede llegar a ser enorme. Además existen ciertas configuraciones que quizá nos gustaría poder gestionar de manera separada, por ejemplo porque son especialmente privadas (claves y cosas así) o quizá porque quiénes deben gestionarlas son otras personas.

Un ejemplo muy habitual son las cadenas de conexión a las bases de datos. Otro también común es la lista de reglas del módulo de re-escritura de URLs de IIS (módulo URLRewrite, equivalente al conocido .htaccess de Apache, si no lo conoces ya estás tardando).

En concreto con URL Rewrite hay ocasiones en las que el archivo puede ser kilométrico, sobre todo si utilizamos mapeos de direcciones para redirigir muchas direcciones antiguas a nuevas. Además, si la gestión de esto la lleva un webmaster o alguien de sistemas que no tiene por qué ser programador, no querremos que meta las zarpas en nuestro precioso archivo de configuración.

En estos casos lo más inteligente es extraer fuera de web.config la información que queramos tratar individualmente.

Para ello el "truco" es utilizar un útil atributo de las secciones de configuración llamado configSource. Este atributo permite indicar el nombre de un archivo en el que se almacena el contenido del nodo de configuración al que se le aplica.

Por ejemplo, consideremos un nodo de configuración de URLRewrite para mapas de direcciones, que sería algo así:

<rewriteMaps>  
  <rewriteMap name="Páginas Eliminadas">  
    <add key="/carpetaVieja/articulo.html" value="/CarpetaNueva/articulo/" />  
    <add key="/productos.php" value="/Catálogo/" />  
    ......
  </rewriteMap>  
</rewriteMaps>

Este tipo de listas puede ser larguísima, y además pueden existir varias (varios nodos de tipo rewriteMap).

Podemos llevarlas individualmente, cada una a un archivo externo, o todas juntas en un único archivo para los mapas usando este atributo.

Por ejemplo, si cambiamos todo lo anterior por esto:

<rewriteMaps configSource="mapas.config" />

ahora podremos crear un archivo en disco llamado mapas.config que contendrá los nodos necesarios para definir las re-escrituras, es decir, contendrá exactamente lo mismo que el primer fragmento de configuración:

<rewriteMaps>  
  <rewriteMap name="Páginas Eliminadas">  
    <add key="/carpetaVieja/articulo.html" value="/CarpetaNueva/articulo/" />  
    <add key="/productos.php" value="/Catálogo/" />  
    ......
  </rewriteMap>  
</rewriteMaps>

Lo que hace ASP.NET es sustituir el nodo con el atributo configSource por el contenido del archivo, lo que enla práctica deja el web.config como estaba inicialmente. pero para nosotros la cosa cambia puesto que ahora podemos gestionar esta configuración en particular de manera separada a las otras.

Podemos repetir este proceso con todas las secciones que nos interesen, reduciendo el tamaño del archivo y dándole acceso a cada cosa a quién verdaderamente lo necesita. Además de este modo podremos tener también archivos diferentes de ciertas configuraciones para desarrollo, pruebas y producción, por ejemplo, gestionándolos de manera más cómoda y segura.

Nota: un detalle importante a tener en cuenta es que cuando modificamos uno de estos archivos, al contrario que cuando modificamos el web.config, la configuración de la aplicación no se recarga de inmediato y no tienen efecto hasta que se recicle el proceso actual. Esto puede ser algo que busquemos conscientemente y nos resulte útil. Si no es el caso y queremos que entren en acción los cambios tan pronto como se produzcan deberíamos tocar el web.config o bien hacer algo que provoque el reciclado de la aplicación (por ejemplo, crear y borrar una carpeta en la raíz de la aplicación). Tenlo en cuenta.

¡Espero que te parezca útil!

José Manuel Alarcón José Manuel Alarcón
Fundador y director de campusMVP.es, el proyecto de referencia en formación on-line para programadores en lengua española. Autor de varios libros y cientos de artículos. Galardonado como MVP de Microsoft desde 2004. Gallego de Vigo, amante de la ciencia y la tecnología, la música y la lectura. Ayudando a la gente en Internet desde 1996.
Descarga GRATIS mi último libro (no técnico): "Tres Monos, Diez Minutos".
Banner

Comentarios (5) -

Excelente tip!!!

Responder

José Miguel

Hola, estoy buscando ayuda con un tema y Google me trajo a tu artículo. No es exactamente esto lo que me ocurre. Te resumo y si te suena y puedes ayudarme te lo agradecería. El caso es que estoy migrando unas aplicaciones aspx que utilizan la infraestructura de SharePoint 2007 a SharePoint 2013. Bien, una de las aplicaciones la tengo publicada en su directorio virtual y desde Visual Studio, me atacho al proceso del IIS y puedo debuggear sin problemas la aplicación. Pero tengo otra, de estructura similar, que le ocurre una cosa curiosa....está publicada en desarrollo bajo el puerto 8091 y cuando lanzo el portal y me atacho al proceso del IIS para debuggear me ocurre que no me está le yendo el web.config situado en su Site (bajo ese puerto), si no que se me está leyendo el web.config ubicado en el Servicio de Token de seguridad  (todas las app's migradas usan un CustomMembershipProvider contra LDAP y entre otras cosas, hay que configurar el web.config de ese servicio de seguridad, pero también están los de las otras aplicaciones y no ocurre lo mismo) y desconozco el motivo. Entonces, al no estar leyendo de su web.config si no de otro no recupera conexiones a BBDD y demás y casca.
¿Tienes alguna idea de qué puede ocasionar el que esté usando otro web.config? Cualquier ayuda será muy bien recibida. Gracias.

Responder

by Jose M. Alarcon

Hola José Miguel:

No tengo mucha experiencia con SharePoint, pero sí la suficiente como para decirte que todo lo que tiene que ver con este producto "on premises" es un verdadero dolor de muelas. Especialmente el manejo "sui-generis" que hace de IIS. Así que siento no poder ayudarte, pero podría ser de cualquier cosa.

De todos modos fíjate en que la carpeta virtual en la que está esa segunda aplicación sea no solo carpeta virtual sino también "App Virtual" (no es lo mismo). Por lo que dices es posible que vayan por ahí los tiros.

Suerte!

Responder

José Miguel

Gracias José Manuel. Realmente los portales están publicados bajo un Site en IIS 8 (cada App con su site y su puerto), me expresé mal. El caso es que las peticiones a la segunda aplicación, por el motivo que sea, lee el web.config de SecurityTokenServices en vez del de su site.....la verdad es que sí, es un dolor de muelas importante.

Gracias de nuevo.

Responder

Augusto Josue A. Cedeño Picón

Buen dato!

Responder

Agregar comentario