.net - tiempo - no se ha declarado el elemento configuration

Cómo seleccionar diferentes app.config para varias configuraciones de compilación

Question

Tengo un proyecto tipo dll que contiene las pruebas de integración MSTest. En mi máquina, las pruebas pasan, y quiero que ocurra lo mismo en un servidor de CI (uso TeamCity). Pero las pruebas fallan, porque necesito ajustar algunas configuraciones en app.config. Es por eso que estaba pensando en tener un segundo archivo app.config por separado que contendrá la configuración para el servidor CI.

Entonces me gustaría tener

/Sln /Proj app.config (I think this is required by VS) app.Release.config (This is a standalone independent config file)

Por lo tanto, si selecciono la configuración de liberación en la configuración de compilación en CI, me gustaría utilizar el archivo app.Release.config en lugar de app.config

Problema
Esto no parece ser sencillo para proyectos de tipo simple .dll. Para proyectos web, puedo hacer transformaciones de configuración web. Encontré un hack sobre cómo hacer estas transformaciones para un proyecto tipo dll, pero no soy un gran fanático de los hacks.

Pregunta
¿Cuál es un enfoque estándar para ajustar archivos app.config dependiendo de la configuración de compilación para proyectos .NET (como Debug, Release, ...)?

Answer 1

Deberías considerar ConfigGen . Fue desarrollado para este propósito. Produce un archivo de configuración para cada máquina de implementación, basado en un archivo de plantilla y un archivo de configuración. Sé que esto no responde su pregunta específicamente, pero bien podría responder a su problema.

Entonces, en lugar de Depurar, Liberar, etc., puede tener Prueba, UAT, Producción, etc. También puede tener configuraciones diferentes para cada máquina desarrolladora, de modo que pueda generar una configuración específica para su máquina de desarrollo y cambiarla sin afectar la implementación de otra persona. .

Un ejemplo de uso podría ser ...

<Target Name="BeforeBuild">
    <Exec Command="C:/Tools/cfg -s $(ProjectDir)App.Config.Settings.xls -t       
        $(ProjectDir)App.config.template.xml -o $(SolutionDir)ConfigGen" />

    <Exec Command="C:/Tools/cfg -s $(ProjectDir)App.Config.Settings.xls -t
        $(ProjectDir)App.config.template.xml -l -n $(ProjectDir)App.config" />
</Target>

Si coloca esto en su archivo .csproj, y tiene los siguientes archivos ...

$(ProjectDir)App.Config.Settings.xls

MachineName        ConfigFilePath   SQLServer        

default             App.config      DEVSQL005
Test                App.config      TESTSQL005
UAT                 App.config      UATSQL005
Production          App.config      PRODSQL005
YourLocalMachine    App.config      ./SQLEXPRESS


$(ProjectDir)App.config.template.xml 

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
   <configuration>
   <appSettings>
       <add key="ConnectionString" value="Data Source=[%SQLServer%]; 
           Database=DatabaseName; Trusted_Connection=True"/>
   </appSettings>
</configuration>

... entonces este será el resultado ...

Desde el primer comando, un archivo de configuración generado para cada entorno especificado en el archivo xls, ubicado en el directorio de salida $ (SolutionDir) ConfigGen

.../solutiondir/ConfigGen/Production/App.config

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
   <configuration>
   <appSettings>
       <add key="ConnectionString" value="Data Source=PRODSQL005; 
           Database=DatabaseName; Trusted_Connection=True"/>
   </appSettings>
</configuration>

Desde el segundo comando, el App.config local utilizado en su máquina dev se reemplazará con la configuración generada especificada por el conmutador local (-l) y el conmutador de nombre de archivo (-n).

Answer 2

Después de investigar un poco sobre la administración de las configuraciones para el desarrollo y las compilaciones, etc., decidí lanzar el mío, lo he hecho disponible en bitbucket en: https://bitbucket.org/brightertools/contemplate/wiki/Home

Esta configuración múltiple de archivos para múltiples entornos, es una herramienta básica de reemplazo de entrada de configuración que funcionará con cualquier formato de archivo basado en texto.

Espero que esto ayude.

Answer 3

Estoy usando la herramienta XmlPreprocess para la manipulación de archivos de configuración. Está utilizando un archivo de mapeo para múltiples entornos (o múltiples objetivos de compilación en su caso). Puede editar el archivo de mapeo por Excel. Es muy fácil de usar.

Answer 4

He resuelto este tema con la solución que he encontrado aquí: http://www.blackwasp.co.uk/SwitchConfig.aspx

En resumen, lo que dicen es: "al agregar un evento de creación posterior. [...] Necesitamos agregar lo siguiente:

if "Debug"=="$(ConfigurationName)" goto :nocopy
del "$(TargetPath).config"
copy "$(ProjectDir)/Release.config" "$(TargetPath).config"
:nocopy

Answer 5

Puedes probar el siguiente enfoque:

1. Haga clic derecho en el proyecto en el Explorador de soluciones y seleccione Descargar proyecto .
2. El proyecto será descargado. Haga clic derecho en el proyecto de nuevo y seleccione Editar <YourProjectName> .csproj .
3. Ahora puede editar el archivo del proyecto dentro de Visual Studio.
4. Ubique el lugar en el archivo * .csproj donde se incluye el archivo de configuración de la aplicación. Se verá así:

<ItemGroup> <None Include="App.config"/> </ItemGroup>

1. Reemplace esta línea con la siguiente:

<ItemGroup Condition=" ''$(Configuration)'' == ''Debug'' "> <None Include="App.Debug.config"/> </ItemGroup> <ItemGroup Condition=" ''$(Configuration)'' == ''Release'' "> <None Include="App.Release.config"/> </ItemGroup>

No he probado este enfoque para los archivos app.config , pero funcionó bien con otros elementos de proyectos de Visual Studio. Puede personalizar el proceso de compilación de casi cualquier forma que desee. De todos modos, hágamelo saber el resultado.

Answer 6

SlowCheetah y FastKoala de la Galería de VisualStudio parecen ser muy buenas herramientas que ayudan con este problema.

Sin embargo, si desea evitar complementos o utilizar los principios que implementan más extensamente a lo largo de sus procesos de compilación / integración, agregar esto a sus archivos msbuild * proj es una solución abreviada.

Nota: esto es más o menos una repetición del número 2 de la respuesta de @ oleksii.

Esto funciona para proyectos .exe y .dll:

  <Target Name="TransformOnBuild" BeforeTargets="PrepareForBuild">
    <TransformXml Source="App_Config/app.Base.config" Transform="App_Config/app.$(Configuration).config" Destination="app.config" />
  </Target>

Esto funciona para proyectos web:

  <Target Name="TransformOnBuild" BeforeTargets="PrepareForBuild">
    <TransformXml Source="App_Config/Web.Base.config" Transform="App_Config/Web.$(Configuration).config" Destination="Web.config" />
  </Target>

Tenga en cuenta que este paso ocurre incluso antes de que comience la construcción propiamente dicha. La transformación del archivo de configuración ocurre en la carpeta del proyecto. De modo que el web.config transformado está disponible cuando está depurando (un inconveniente de SlowCheetah).

Recuerde que si crea la carpeta App_Config (o lo que usted elija para llamarla), los diversos archivos de configuración intermedios deben tener una Acción de compilación = Ninguno, y Copiar en el directorio de salida = No copiar.

Esto combina ambas opciones en un bloque. El apropiado se ejecuta en base a las condiciones. La tarea TransformXml se define primero:

<Project>
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)/Microsoft/VisualStudio/v$(VisualStudioVersion)/Web/Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="TransformOnBuild" BeforeTargets="PrepareForBuild">
    <TransformXml Condition="Exists(''App_Config/app.Base.config'')" Source="App_Config/app.Base.config" Transform="App_Config/app.$(Configuration).config" Destination="app.config" />
    <TransformXml Condition="Exists(''App_Config/Web.Base.config'')" Source="App_Config/Web.Base.config" Transform="App_Config/Web.$(Configuration).config" Destination="Web.config" />
</Target>

Answer 7

Usando el mismo enfoque que Romeo, lo adapté a Visual Studio 2010:

 <None Condition=" ''$(Configuration)'' == ''Debug'' " Include="appDebug/App.config" />

 <None Condition=" ''$(Configuration)'' == ''Release'' " Include="appRelease/App.config" />

Aquí debe mantener ambos archivos App.config en diferentes directorios (appDebug y appRelease). ¡Lo probé y funciona bien!

Answer 8

Use el complemento SlowCheetah . Para obtener más opciones y detalles sobre cómo usar SlowCheetah sigue leyendo.

Como ya habrás notado, no existe una manera predeterminada y fácil de usar diferentes archivos de configuración para un proyecto de tipo Biblioteca (.dll) . La razón es que el pensamiento actual es: "¡No es necesario"! Los desarrolladores de Framework reconocen que necesita configuración para el archivo ejecutable: ya sea una consola, escritorio, web, aplicación móvil u otra cosa. Si comienzas a proporcionar configuración para un dll , puedes terminar con algo que puedo llamar un infierno de la configuración . Es posible que ya no comprenda (fácilmente) por qué esta y esas variables tienen esos valores extraños que aparecen aparentemente de la nada.

"Espera", - puedes decir, "¡pero necesito esto para mi integración / prueba de unidad, y es una biblioteca!". Y eso es cierto, y esto es lo que puedes hacer (elegir solo uno, no mezclar):

1. SlowCheetah - transforma el archivo de configuración actual

Puede instalar SlowCheetah , un complemento de Visual Studio que hace todo el SlowCheetah bajo nivel de XML (o transformación) por usted. La forma en que funciona, brevemente:

• Instale SlowCheetah y reinicie Visual Studio (Visual Studio> Herramientas> Extensiones y actualizaciones ...> En línea> Galería de Visual Studio> busque "Slow Cheetah")
• Defina las configuraciones de su solución ( Debug and Release están ahí por defecto), puede agregar más (haga clic con el botón secundario en la solución en Solution Explorer > Configuration Manager ... > Configuración de la solución activa > Nuevo ...
• Agregue un archivo de configuración si es necesario
• Haga clic derecho en el archivo de configuración> Agregar transformación
  • Esto creará archivos de Transformación, uno por su configuración
  • Los archivos de transformación funcionan como inyectores / mutadores, encuentran el código XML necesario en el archivo de configuración original e inyectan nuevas líneas o modifican el valor necesario, sea lo que sea que le diga que haga.

2. Fiddle con el archivo .proj - copia-cambia el nombre de un archivo de configuración completamente nuevo

Originalmente tomado de here . Es una tarea personalizada de MSBuild que puede incrustar en el archivo .proj de Visual Studio. Copie y pegue el siguiente código en el archivo de proyecto

<Target Name="AfterBuild">
    <Delete Files="$(TargetDir)$(TargetFileName).config" />
    <Copy SourceFiles="$(ProjectDir)/Config/App.$(Configuration).config"
          DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>

Ahora crea una carpeta en el proyecto llamada Config y agrega nuevos archivos allí: App.Debug.config , App.Release.config , y así sucesivamente. Ahora, según su configuración, Visual Studio seleccionará el archivo de configuración de una carpeta Config y lo copiará y lo cambiará al directorio de salida. Por lo tanto, si tiene el proyecto PatternPA.Test.Integration y una configuración de Debug seleccionada, en la carpeta de salida después de la compilación encontrará un archivo PatternPA.Test.Integration.dll.config que se copió de Config/App.Debug.config y cambió de nombre. después.

Estas son algunas notas que puedes dejar en los archivos de configuración

<?xml version="1.0" encoding="utf-8"?>
<configuration>

    <!-- This file is copied and renamed by the ''AfterBuild'' MSBuild task -->

    <!-- Depending on the configuration the content of projectName.dll.config 
        is fully substituted by the correspondent to build configuration file 
        from the ''Config'' directory. -->

</configuration>

En Visual Studio puedes tener algo como esto

3. Usa archivos de scripting fuera de Visual Studio

Cada herramienta de compilación (como NAnt , MSBuild ) proporcionará capacidades para transformar archivos de configuración según la configuración. Esto es útil si construye su solución en una máquina de construcción, donde necesita tener más control sobre qué y cómo prepara el producto para su lanzamiento.

Por ejemplo, puede usar la tarea de dll de publicación web para transformar cualquier archivo de configuración

<UsingTask AssemblyFile="../tools/build/Microsoft.Web.Publishing.Tasks.dll"
    TaskName="TransformXml"/>

<PropertyGroup>
    <!-- Path to input config file -->  
    <TransformInputFile>path to app.config</TransformInputFile>
    <!-- Path to the transformation file -->    
    <TransformFile>path to app.$(Configuration).config</TransformFile>
    <!-- Path to outptu web config file --> 
    <TransformOutputFile>path to output project.dll.config</TransformOutputFile>
</PropertyGroup>

<Target Name="transform">
    <TransformXml Source="$(TransformInputFile)"
                  Transform="$(TransformFile)"
                  Destination="$(TransformOutputFile)" />
</Target>

Answer 9

Vea si el motor de transformación XDT (web.config) puede ayudarlo. Actualmente solo es compatible de forma nativa para proyectos web, pero técnicamente no hay nada que le impida usarlo en otros tipos de aplicaciones. Hay muchas guías sobre cómo usar XDT editando manualmente los archivos del proyecto, pero encontré un complemento que funciona muy bien: https://visualstudiogallery.msdn.microsoft.com/579d3a78-3bdd-497c-bc21-aa6e6abbc859

El complemento solo está ayudando a configurar la configuración, no es necesario compilarla y la solución se puede construir en otras máquinas o en un servidor de compilación sin necesidad de utilizar el plugin ni ninguna otra herramienta.