c# - ejemplo - habilitar errores web config

¿Cómo maneja varios archivos web.config para múltiples entornos?

Question

La forma en que actualmente manejo esto es tener varios archivos de configuración como:

web.config
web.Prod.config
web.QA.config
web.Dev.config

Cuando el proyecto se implementa en los diferentes entornos, simplemente cambio el nombre del archivo correspondiente con la configuración correcta.

¿Alguien tiene sugerencias sobre cómo manejar esto mejor?

EDITAR: Estas son algunas de las cosas que cambian en cada configuración:

• WCF Client Endpoint urls y seguridad
• Configuraciones de base de datos personalizadas
• Cadenas de conexión de sesión
• configuración log4net

Answer 1

A través de la mayoría del software de administración de versiones (subversion, git, etc.) puede ignorar archivos específicos.

Así, en la subversión, tendría:

configure.template.php: este archivo está versionado y contiene datos de configuración con plantilla, como configure.php de DSN vacío: este archivo se ignora, por lo que los cambios no se rastrean.

En subversion, la forma de hacerlo es:

svn pe svn: ignorar. Abrirá su editor, luego escriba configure.php

Guarde, salga, registre sus cambios y listo.

Answer 2

En Visual Studio, creo eventos de compilación de xcopy y almaceno todos los archivos de configuración en una carpeta / config. Solo necesita un evento para todas las configuraciones si nombra sus archivos después de la configuración de compilación: es decir, sobrescribiendo web.config con /config/web.$(Configuration).config

Answer 3

La forma en que lo hemos estado haciendo es anular la sección AppSettings:

<appSettings file="../AppSettingsOverride.config">
    <add key="key" value="override" />    
    ...
</appSettings>

Esto solo funciona para la sección de ajustes de aplicaciones y, por lo tanto, solo es útil hasta cierto punto. Estaría muy interesado en soluciones más robustas.

Editar abajo

Acabo de ver esto: http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/

VS2010 tiene transformaciones de configuración que parecen bastante impresionantes, deberían hacer que las configuraciones múltiples sean una brisa completa.

Answer 4

Las transformaciones parecen realmente útiles para esto. Puede reemplazar ciertas secciones con diferentes reglas.

http://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx

Answer 5

Mi forma favorita de abordar esto es con el atributo configSource . Es cierto que solo uso esto en un elemento ( <connectionStrings> ) pero proporciona una manera fácil de intercambiar y extraer diferentes segmentos de un web.config (lo que hago durante el tiempo de instalación a través de un proyecto WebSetup).

Answer 6

Realmente depende de cuál sea la diferencia entre los entornos que están causando el uso de diferentes archivos web.config. ¿Puede dar más información sobre por qué cada entorno necesita actualmente uno diferente?

Answer 7

Scott Gu tenía un article sobre esto una vez. La solución que presentó fue usar un evento de Pre-compilación para copiar la configuración correcta en su lugar, dependiendo de la configuración de compilación elegida.

También noté que ya hay una question similar aquí en SO.

Answer 8

También uso el web.DEV.config, web.TEST.config, web.PROD.config etc.

De esta manera, considero que la forma más sencilla, sencilla y directa si sus proyectos no son complejos. No me gusta hacer las cosas más complicadas de lo necesario.

Sin embargo, he usado NAnt y creo que funciona bien para esto. Puede configurar compilaciones para sus diferentes entornos. NAnt toma algunas lecturas para aprender a usarlo, pero es bastante flexible.

http://aspnet.4guysfromrolla.com/articles/120104-1.aspx

http://nant.sourceforge.net/

Lo usé junto con CruiseControl.net y NUnit para realizar compilaciones diarias automáticas con validación de prueba unitaria y pensé que funcionaban bien juntos.

Answer 9

Tenemos algunas soluciones (no todas se realizan con web.config, pero la misma idea)

1. Incluimos múltiples archivos de configuración en la implementación empaquetada. Durante la instalación especificamos el entorno en el que estamos instalando.
2. Migre todas las configuraciones específicas del entorno al servidor de base de datos para ese entorno. El servidor web proporciona su entorno cuando solicita el nombre del servidor
3. Proporcione configuraciones múltiples (1 por entorno) y utilice la configuración de solicitud de código diferente.
4. Combinación de 2 y 3 (Anular una parte de la configuración basada en el entorno, por ejemplo, el nombre del servidor de la aplicación)