.net - studio - Gestionar archivos complejos de Web.Config entre entornos de despliegue

wcf ajax

Question

¿Alguien sabe de alguna buena herramienta / utilidad para administrar archivos Web.Config entre diferentes entornos de compilación / implementación?

Por ejemplo, tengo un proyecto WCF que, en desarrollo, no quiero habilitar SSL, pero sí quiero que esté habilitado en producción. Quiero diferentes configuraciones de registro, diferentes cadenas de conexión de DB, manejo de errores diferentes, diferentes rutas de archivos ... Incluso algunos enlaces de framework de Unity diferentes (wire up mocks para pruebas unitarias en lugar de los objetos reales para implementación).

Mantener las copias individuales de Web.Config es un problema, porque agregar un nuevo servicio web significa editar varios archivos y mantenerlos sincronizados.

También me he dado cuenta de que si Web.Config el Web.Config demasiado a mano, Visual Studio se ahogará si tratas de usar el asistente "agregar elemento" para, digamos, agregar un nuevo servicio web para WCF, ya que tiene que modifique el Web.Config para agregar el punto final, y nd no puede analizarlo más. Por lo tanto, debo tener cuidado de no invalidar el Web.Config existente.

También pensé en usar solo Web.Config regulares para hacer reemplazos y simplemente construir un nuevo Web.Config en un comando previo a la compilación. Esa parece ser la mejor opción hasta ahora ...

¿Alguna otra idea? Parece que esto debería ser un problema muy común, ya que Web.Config probablemente nunca debería ser el mismo entre las implementaciones de desarrollo y producción.

Actualizar:

Decidí escribir una aplicación de consola rápida que tomará todos los archivos xml en un directorio determinado y los fusionará en uno, y solo incluirá ciertos archivos basados ​​en el nombre.

Entonces puedo hacer en un directorio:

WebConfig_All

<configuration>
<configSections>
...
</configSections>
<system.web>
...
</system.web>
</configuration>

connectionStrings_Debug

<configuration>
<connectionStrings>
<add name="connstr" connectionString="...dev..." />
</connectionStrings>
</configuration>

connectionStrings_Release

<configuration>
<connectionStrings>
<add name="connstr" connectionString="...prod..." />
</connectionStrings>
</configuration>

Luego ejecute mi herramienta de línea de comando y pase la configuración (Depurar, Liberar, Personalizar ...) Y fusionará todos los archivos que terminan en _All" or _ <configuración>`.

Así que ahora tengo el 80% de mi Web.Config en un solo archivo WebConfig_All , y el 20% de cosas personalizadas en archivos separados por configuración de compilación. Luego puedo ejecutar mi herramienta de línea de comando como una tarea previa a la construcción en VisualStudio, o desde NAnt, o donde yo quiera ...

También hice mi lógica de combinación de XML lo suficientemente buena como para manejar cosas como:

<x>
<y a="1">
<z a="1"/>
</y>
</x>

fusionarse con

<x>
<y a="1">
<z a="2"/>
</y>
<y a="2"/>
</x>

resultados en:

<x>
<y a="1">
<z a="1"/>
<z a="2"/>
</y>
<y a="2"/>
</x>

Se ve bien hasta ahora ... :)

Seguir:

Este tema es un poco viejo ahora, así que quería señalar que VisualStudio 2010 tiene una función para hacer las transformaciones web.config integradas: http://msdn.microsoft.com/en-us/vstudio/Video/ff801895

Por supuesto, en la manera típica de Microsoft de implementar solo cualquier función el 50% del camino, solo funciona para proyectos web que utilizan despliegue web. Hay un complemento para habilitar transformaciones en otros proyectos, que se encuentra aquí: http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx

También puede usar una herramienta como BuildMaster para administrar archivos de configuración (junto con compilaciones, pruebas, scripts DB, etc.)

Answer 1

Desea la tarea XmlMassUpdate en MSBuildCommunityTasks (hace lo que intenta hacer con su aplicación de consola xml)

http://msbuildtasks.tigris.org/

Úselo así

 <XmlMassUpdate Condition=" ''@(ConfigTemplateFile)''!='''' And ''@(ConfigSubstitutionsFile)''!=''''"
ContentFile="@(ConfigTemplateFile)"
SubstitutionsFile="@(ConfigSubstitutionsFile)"
MergedFile="@(ConfigFile)"
ContentRoot="/configuration"
SubstitutionsRoot="/configuration/substitutions/$(Configuration)"/>

Answer 2

Dividimos todas las configuraciones específicas de la región en su propio archivo de configuración. Debajo de la raíz de la aplicación web, creamos una carpeta de configuración y colocamos allí la configuración específica de la región. Entonces, cualquier archivo que esté viviendo bajo la raíz de config será recogido.

nuestro web.config se ve algo así como:

.
.
.
<appSettings configSource="config/appSettings.config"/>
<nlog configSource="config/nlog.config"/>
<applicationSettings>
<MyApp.UI.Properties.Settings configSource="config/Settings.APGUI.config"/>
<MyApp.BusinessServices.Properties.Settings configSource="config/Settings.Business.config"/>
<MyApp.Auditing.Properties.Settings configSource="config/Settings.Auditing.config"/>
</applicationSettings>
.
.
.

Entonces, si estamos desplegando en la región de lanzamiento, la herramienta de compilación tendrá una acción para reemplazar los archivos en la raíz de la configuración con los archivos de la carpeta regional correspondiente. La estructura del archivo se ve algo así como:

AÑADIDO: así es como se ve la estructura de control de origen, la aplicación desplegada solo tendría el directorio de configuración sin subcarpetas o curso

/Root
web.config
/Config
appsettings.config
services.config
logging.config
/release
appsettings.config
services.config
logging.config
/debug
appsettings.config
services.config
logging.config

Está bastante limpio y es compatible con cualquier herramienta de compilación automatizada (copiar / reemplazar archivos). El lado agradable es que los desarrolladores pueden crear diferentes sabores y mantenerlos bajo el control de la fuente sin afectar las configuraciones "reales".

Answer 3

Me gusta utilizar una tarea de compilación para automate cambio del archivo de configuración para el entorno deseado.

Answer 4

Mis dos formas favoritas de lidiar con esto son:

A. Mantenga la configuración en la máquina de destino *: en Azure, por ejemplo, puede configurar la configuración de la aplicación y las cadenas de conexión que anularán los valores en web.config. (* - o definición de la máquina de destino si la configuración de su infraestructura es dinámica).

B. Haga que la herramienta de compilación / implementación (TeamCity, Octopus Deploy, etc., VS Team Services) incorpore los valores específicos del entorno como parte de la compilación y / o implementación. Las herramientas modernas admiten el cifrado de configuraciones confidenciales.

Answer 5

Molestia:

Mencioné mi pequeña aplicación de línea de cmd para combinar documentos XML en mi primera actualización ... Bueno, para hacer eso solo uso XmlDocument, y eventualmente simplemente .Guardarlo () en un FileStream.

Desafortunadamente, los nodos no están realmente en un orden particular, y aparentemente, .NET requiere que el elemento <configSections> sea el primer hijo del documento.

Pensé que se suponía que todas estas herramientas de fantasía facilitarían la vida de programación.

Answer 6

Puede usar Build Events para administrar sus configuraciones web. Hanselman tiene un buen artículo al respecto.

Básicamente, tienes todos tus contactos web diferentes en la solución y luego creas (algunos) nuevos tipos de compilación. Dependiendo del tipo de compilación que ejecute, ¡web.config se copia sobre el referido!

Answer 7

Tradicionalmente he usado los múltiples web.configs como mencionaste. Puede ser un problema, pero se ve mitigado por herramientas de comparación de archivos como BeyoneComapare2 o KDIff ...

Answer 8

Una vieja pregunta, pero dado que tiene un alto rango en la búsqueda de Google, pensé que era una buena idea agregar la sintaxis de transformación web.config , que ha estado disponible desde VS2010 . Con esta herramienta, puede tener diferentes archivos web.config para diferentes compilaciones (depuración / versión)

Aquí hay un breve resumen sobre cómo tener dos cadenas de conexiones: una para el desarrollo (modo Debug) y otra para la producción (modo Release):

1- Configure su cadena de conexión de desarrollo en el archivo web.config. Debería verse similar a esto:

 <connectionStrings>
<add name="myConnectionString" connectionString="Data Source=TestDBServer; (etc...)" />
</connectionStrings>

2- Expande tu archivo web.config y abre web.release.config

3- Utilice la función Replace para reemplazar la cadena de conexión por la que desee para la producción. Puede usar el xdt:Locator="Match(name)" para que coincida con el nombre de la cadena de conexión (myConnectionString) en este ejemplo:

<connectionStrings>
<add name="myConnectionString" xdt:Transform="Replace" xdt:Locator="Match(name)"
connectionString="Data Source=ProdDBServer; (etc...)" />
</connectionStrings>

4- Obtenga una vista previa de la transformación del archivo web.config que se usará durante la creación del lanzamiento haciendo clic con el botón derecho en el archivo web.release.config y eligiendo Vista Previa Transformar .

Answer 9

Uso el Hanselman (lo explica mucho mejor de lo que puedo reproducir esto, así que sigan el enlace :)) Me ha funcionado bien ...

Answer 10

Utilizamos etiquetas en nuestros archivos de configuración, que se reemplazan en el momento de la compilación para reflejar el entorno de despliegue previsto. Me inspiré en el blog Lavablast

Es bueno tener solo un archivo de configuración de plantilla para administrar.

El inconveniente es que no puede tener fácilmente "secciones" personalizadas.

Answer 11

Yo uso esta herramienta: xmlpreprocess

mantenemos archivos separados de "propiedad" para cada entorno que se fusiona con el script de despliegue.