asp.net - studio - Diferenciando web.config entre entornos dev, staging y producción

web config release connection string

Question

¿Alguien tiene buenos consejos para manejar las diferencias en la configuración de web.config entre entornos? Consideré crear una carpeta ''config'' en nuestro sistema de control de origen, pero fuera de la jerarquía web, y hacer que el proceso de implementación copie los archivos de configuración apropiados (web.dev.config, web.staging.config, web.production.config ) en la carpeta web al momento de la implementación. También he visto publicaciones sobre cómo cambiar las configuraciones por programación (puntos finales WCF, cadenas de conexión, etc.) cuando se inicia la aplicación.

¿Qué se consideran las mejores prácticas aquí, y qué experiencias ha tenido cada uno con estos u otros enfoques?

Actualización Sep 2010

Vale la pena señalar que Visual Studio 2010 agrega esta capacidad a través de las transformaciones web.config . Cuando utiliza el administrador de configuración de compilación (Build | Configuration Manager ...) para crear diferentes configuraciones para su proyecto (por ejemplo, Debug, Dev, Staging y Release), VS agrega archivos de configuración web. * .con la solución. El archivo web.config predeterminado contiene la configuración de línea base que usará para la depuración. web.release.config, web.staging.config, etc. contienen transformaciones XSLT que se aplicarán cada vez que publique su proyecto en función de la configuración de compilación activa.

Answer 1

Mi enfoque ha sido tener múltiples archivos de configuración. Puse todas las cosas de entorno independiente (es decir, no importa si dev, puesta en escena o producción) en el archivo web.config. Cualquier cosa que sea específica para el entorno (es decir, información de conexión a la base de datos, registro, configuración de depuración, etc.) pongo en un archivo local.config específico para el entorno. A continuación, puede incluir la configuración local.config en web.config usando configSource ( http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx )

Web.config se puede verificar en el control de origen. No verifique los archivos local.config, lo que le obliga a implementar el correcto en sus scripts de implementación.

Answer 2

Hay un tipo de proyecto llamado Proyecto de implementación web , disponible de forma gratuita desde Microsoft que le permite hacer exactamente eso. Puedes reemplazar secciones de tu web.config, dependiendo de la configuración de tu solución (depuración, versión, etc.). Usamos eso por más de un año y funciona bien. Está disponible para VS2005 y VS2008.

Espero que esto ayude

Answer 3

Un método que he visto y usado es donde configura las claves dentro de su web.config para diferenciar las computadoras por su nombre.

Entonces, por ejemplo:

<add key="comp1.Environment" value="DEV"/>
<add key="compdb1.Environment" value="PROD"/>
<add key="compstage.Environment" value="STAGE"/>

Obviamente, comp1, compdb1 son los nombres reales de las computadoras.

Luego, configuraría algo como:

<add key="KeyName,DEV" value="DevEnvironmentValue"/>

En su código, debería verificar en qué entorno se está ejecutando la aplicación y luego obtener la clave adecuada, por ejemplo.

private string GetKeyValue() {
string machineName = String.Concat(System.Environment.MachineName, ".Environment");
string environment = ConfigurationManager.AppSettings[machineName];
string key = String.Concat("KeyName", ",", environment);
string keyValue = ConfigurationManager.AppSettings[key];
return keyValue;
}

Answer 4

Yo uso CruiseControl.NET/NAnt y NAnt tiene una tarea XMLPoke que te permite entrar mientras construyes y alterar cualquier configuración mediante consultas XPath.

Entonces, en cada uno de mis objetivos de compilación (DEV, UAT, STAGING, etc.) configuré un conjunto de propiedades y luego llamé al objetivo de compilación maestra. El objetivo de compilación maestra toma los valores de todas las propiedades y XML los ubica en las configuraciones y compilaciones.

Answer 5

Si bien algunas de las otras respuestas pueden ser más adecuadas, agregaré que Matt Berseth rodó su propio método en 2007 ...

En resumen, mantiene todos los valores que varían entre entornos en un archivo de texto exclusivo y utiliza una herramienta personalizada durante el proceso de compilación para fusionar los valores en los archivos .config.

En un comentario sobre esa publicación, Doron Yaacoby también comenta:

"hay una tarea en MSBuild Community Tasks que puede lograr esto (y más) para usted, que se llama XmlMassUpdate. He escrito sobre esto en mi blog "

Answer 6

Con el nuevo VS puedes usar transformaciones de configuración web.

Lea más aquí: http://msdn.microsoft.com/en-us/library/dd465326.aspx

Answer 7

Necesita INSTALAR para un entorno, NO CONSTRUIR para uno. En el mundo real, debe instalar en prod lo que se probó en QA, no se permite la reconstrucción. Al menos en mi mundo ese es el caso.

Answer 8

A continuación, le mostramos cómo agregar diferentes configuraciones que se pueden personalizar para sus entornos de implementación en VS2012

1. Haga clic con el botón derecho del mouse sobre la solución y seleccione el administrador de configuración
2. Haga clic en el botón Administrador de configuración
3. En la columna Configuración, seleccione el cuadro combinado contra el proyecto al que desea agregar una configuración y seleccione
4. Cree una nueva configuración con un nombre como PRUEBA y copie las configuraciones de Versión y marque la casilla de verificación Crear nuevas configuraciones de solución
5. Haga clic con el botón derecho del mouse en Web.config
6. Agregar configuración de transformación
7. Luego obtienes un web.config extra. Ej. Web.TEST.config

Después de esto, debe modificar web.TEST.config con algunas transformaciones específicas de su entorno TEST