Archivos app.config / web.config específicos del desarrollador en Visual Studio

Tenemos varios proyectos .NET donde almacenamos ciertas configuraciones en archivos de configuración.

Ahora, cada desarrollador tendrá sus propios archivos de configuración que difieren un poco (diferentes cadenas de conexión para conectarse a bases de datos locales, diferentes puntos finales WCF , etc.)

Por el momento, solemos revisar los archivos app / web.config y modificarlos para adaptarlos a nuestras necesidades.

Esto genera muchos problemas, ya que de vez en cuando alguien verifica su propia configuración o pierde la configuración personalizada al obtener la última versión de TFS .

¿Cómo afrontas situaciones como esta? ¿O no tienes este problema en absoluto?

Usamos un sistema que combina varias de las respuestas existentes en esta página y se basa en esta sugerencia de Scott Hanselman .

En resumen, lo que hicimos fue tener una app.config / web.config común y tener la mayoría de las configuraciones específicas en archivos individuales, como lo sugieren otras respuestas aquí. por ejemplo, para nuestra configuración SMTP, el archivo app.config contiene

<system.net>
  <mailSettings>
    <smtp configSource="config\smtp.config" />
  </mailSettings>
</system.net>

Este archivo está en control de código fuente. Sin embargo, los archivos individuales, como este, no son:

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
  <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

Sin embargo, ahí no es exactamente donde termina la historia. ¿Qué pasa con los nuevos desarrolladores o una instalación de fuente nueva? La mayor parte de la configuración ya no está en el control de código fuente, y es complicado crear manualmente todos los archivos .config que necesitan. Prefiero tener una fuente que al menos se compile de inmediato.

Por lo tanto, mantenemos una versión de los archivos .config en el control de código fuente, denominada archivos .config.default . Por lo tanto, un árbol de origen fresco se ve así:

Aún así, no es realmente útil para el desarrollador, ya que para Visual Studio son solo archivos de texto sin sentido. Por lo tanto, el archivo copy_default_config.batpor lotes`` se encarga de crear un conjunto inicial de archivos .config a partir de los archivos .config.default:

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

El script se puede volver a ejecutar de forma segura, ya que los desarrolladores que ya tienen sus archivos .config no los sobrescribirán. Por lo tanto, uno podría posiblemente ejecutar este archivo por lotes como un evento previo a la compilación. Los valores de los archivos .default pueden no ser exactamente correctos para una nueva instalación, pero son un punto de partida razonable.

En última instancia, cada desarrollador termina con una carpeta de archivos de configuración que se parece a esto:

Puede parecer un poco complicado, pero definitivamente es preferible a la molestia de que los desarrolladores se pidan unos a otros.

En su Web.config use la fuente de otros archivos

<configuration>
    <connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

Mantenga web.config en control de versiones y no lo haga para ConnectionStrings.config. Ahora todos los desarrolladores tienen un archivo para la cadena de conexión.

Puede hacer esto para todas las configuraciones que dependen de la localidad.

Aquí una solución para archivos web.config y Visual Studio 2010:

1) Edite manualmente el archivo .csproj de su aplicación web para agregar un AfterBuilddestino como este:

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

Este destino transformará el archivo Web.config correspondiente al desarrollador actual que inició sesión, de ahí la $(USERNAME)variable, con el archivo correspondiente creado en 1). Reemplazará el Web.config local solo si el contenido ha cambiado (para evitar reiniciar) en cada compilación, incluso si el Web.config local está controlado por fuente, es por eso que OverwriteReadOnlyFilesestá establecido en True. De hecho, este punto es discutible.

2) Cree un archivo con el nombre Web.[developer windows login].configde cada desarrollador del proyecto. (por ejemplo, en las siguientes capturas de pantalla tengo dos desarrolladores llamados smo y smo2):

Estos archivos (1 por desarrollador) pueden / deben ser controlados por fuente. No deben marcarse como dependientes del Web.config principal porque queremos poder verificarlos individualmente.

Cada uno de estos archivos representa una transformación para aplicar al archivo Web.Config principal. La sintaxis de transformación se describe aquí: Web.config Sintaxis de transformación para la implementación de proyectos de aplicaciones web . Reutilizamos esta genial tarea de transformación de archivos Xml que viene lista para usar con Visual Studio. El propósito de esta tarea es combinar elementos y atributos Xml en lugar de sobrescribir todo el archivo.

Por ejemplo, aquí hay una muestra web.[dev login].configque cambia una cadena de conexión llamada 'MyDB', independientemente del resto del archivo Web.config:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

Ahora bien, esta solución no es perfecta porque:

• después de la construcción, los desarrolladores pueden tener un Web.Config diferente localmente que en el sistema de control de código fuente
• es posible que tengan que forzar la escritura local cuando obtengan un nuevo Web.Config desde el sistema de control de fuente
• los desarrolladores no deben consultar / en el web.config principal. Debe reservarse para pocas personas.

Pero al menos, solo tiene que mantener un archivo web.config principal único más un archivo de transformación por desarrollador.

Se podría adoptar un enfoque similar para los archivos App.config (no web), pero no di más detalles.

Estamos usando machine.config para evitar tener diferencias en web.config entre los entornos.

¿Qué tal si ignoras el archivo para que nunca se registre? Me encontré con un problema similar y agregué web.config a la lista de ignorados en Subversion.

Sin embargo, en TFS es un poco más difícil, vea esta publicación sobre cómo hacerlo.

Una forma de hacer frente es tener un sistema tokenizado y usar un script de rake para cambiar los valores.

Un método más rudimentario podría ser tener un enlace a un archivo AppSettings.config para todos los AppSettings en su web.config (similar con conexiones) es decir

<appSettings configSource="_configs/AppSettings.config" />

Luego tenga una carpeta con cada uno de sus desarrolladores que tenga una versión en una subcarpeta (es decir, / _configs / dave /). Luego, cuando un desarrollador está trabajando en su propio código, lo copia de la subcarpeta a la raíz de la carpeta vinculada.

Deberá asegurarse de comunicar los cambios a estos archivos (a menos que los tokenice). Si mantiene el archivo AppSettings.config fuera del control de la fuente y solo registra las carpetas individuales de los desarrolladores (todas), entonces se verán obligados a copiar la correcta.

Prefiero la tokenización, pero puede ser más difícil de poner en marcha si esto solo pretende ser una solución rápida.

Ignore los archivos y tenga un Commom_Web.Config y Common_App.Config. Usar un servidor de compilación de integración continua con tareas de compilación que cambian el nombre de estos dos a nombres normales para que el servidor de compilación pueda hacer su trabajo.

Tenemos el mismo problema y lo que estamos haciendo es

• Compruebe en web.config con los valores de testserver / production
• El desarrollador va al explorador de Windows y cambia el modo de solo lectura del archivo
• Edite la configuración para adaptarla a su entorno.
• El registro en web.config ocurre solo cuando los valores de implementación cambian o se agrega o elimina cualquier entrada de configuración.
• Esto necesita una buena cantidad de comentarios para cada entrada de configuración, ya que cada desarrollador debe cambiarla

Suponiendo que está usando Visual Studio, ¿por qué no usa diferentes configuraciones de solución? Por ejemplo: puede tener una configuración de depuración que use Web.config.debug y una configuración de versión que use Web.config.release. Web.config.debug debería tener algo como

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config"> 

con el archivo Standard_Name_For_Config.config que tiene todas las configuraciones personales del desarrollador, mientras que Web.config.release siempre tiene las configuraciones de producción. Puede almacenar configuraciones predeterminadas en alguna carpeta controlada por fuentes y hacer que un nuevo usuario las tome desde allí.