Diferenciando web.config entre entornos dev, staging y producción

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.

¿Cuáles son las mejores prácticas consideradas 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 web.config transforms. 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 siempre que publique su proyecto en función de la configuración de compilación activa.

Answer 1

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

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

Answer 2

Uso CruiseControl.NET/NAnt y NAnt tiene una tarea XMLPoke que le permite entrar mientras construye y modificar 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 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.

Así, 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 de los equipos reales.

A continuación, la configuración algo como:

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

En su código que se necesita para comprobar qué entorno se ejecuta la aplicación y luego obtener la clave adecuada, por lo que 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

Hay un tipo de proyecto llamado Web Deployment project, libremente disponible de Microsoft que le permiten 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.

la esperanza que esto ayudará

Answer 5

Mi enfoque ha sido el de tener varios 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. Todo lo que sea específico del entorno (por ejemplo, información de conexión a la base de datos, registro, configuración de depuración, etc.) lo pongo en un archivo local.config específico para el entorno. A continuación, puede incluir la configuración local.config en web.config utilizando configSource (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx)

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

Answer 6

Mientras que algunas de las otras respuestas pueden ser más adecuados voy a añadir que Matt Berseth rolled his own method de nuevo en 2007 ...

En resumen El guarda todos los valores que varían entre los ambientes en un archivo de texto de propiedad y utiliza un herramienta personalizada durante el proceso de compilación para fusionar los valores en los archivos .config.

En un comentario en ese puesto Doron Yaacoby También Comentarios:

"no es una tarea de MSBuild Comunidad tareas que se pueden lograr esto (y más) para usted, que se llama XmlMassUpdate Ive written about it in my blog. "

Answer 7

es necesario instalar para un entorno, no construye 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

Aquí es cómo agregar diferentes configuraciones que se pueden personalizar para sus entornos de despliegue en VS2012

1. clic con el ratón derecho en la solución y seleccione configuración del gestor de
2. Haga clic en el botón Administrador de configuración
3. bajo la configuración cuadro combinado de selección de columna en el proyecto al que desea agregar una configuración y Seleccionar
4. Crear una nueva configuración con un nombre como PRUEBA y copiar configuraciones de lanzamiento y comprobar la casilla de verificación Crear nueva configuración de soluciones
5. botón derecho del ratón en el Web.config
6. Añadir Config Transform
7. A continuación, se obtiene una web.config adicional Ej web.TEST.config

Después de ello, tiene que modificar web.TEST.config con algunas transformaciones específicas para el entorno de prueba

Answer 9

Easy way to have that is having an Enumeration , then having a switch statement based on the server name (if its stable name) . 
Call GetURIPath() where ever you require to fetch details , here I given the examples for url's used 


public class StaticData 
{ 
    public enum enumEnvironment 
    { 
     envNONE = 0, 
     envLOC = 1, 
     envDEV = 2, 
     envTEST = 3, 
     envPROD = 4 
    } 
    private static enumEnvironment GetCurrentEnv() 
    { 
     if (ConfigurationManager.GetSection("DBSettingsGroup/DBSettings") == null && ConfigurationManager.GetSection("DBSettings") == null) 
     { 
      return enumEnvironment.envLOC; 
     } 
     else 
     { 
      NameValueCollection NVCollection = new NameValueCollection(); 
      NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettingsGroup/DBSettings"); 
      if(NVCollection == null) 
      { 
       NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettings"); 
      } 

      string sEnv = NVCollection.GetValues("serverrole").ToString(); 

      switch (sEnv.ToUpper()) 
      { 
       case "DEV-ISOLATED": 
        return enumEnvironment.envDEV; 
       case "DEVELOPMENT": 
        return enumEnvironment.envDEV; 
       case "TEST": 
        return enumEnvironment.envTEST; 
       case "PRODUCTION": 
        return enumEnvironment.envPROD; 
       default: 
        return enumEnvironment.envNONE; 
      } 
     } 
    } 
    public static string GetURIPath() 
    { 
     switch (GetCurrentEnv()) 
     { 
      case enumEnvironment.envPROD: 
       return "http://produrl/yourapp/api/"; 
      case enumEnvironment.envTEST: 
       return "http://testurl/yourapp/api/"; 
      case enumEnvironment.envDEV: 
       return "http://devurl/yourapp/api/"; 
      default: 
       return "http://localhost/yourapp/api/"; 
     } 
    } 

}