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

Question

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 db local, diferentes puntos finales WCF, etc.)

Por el momento, tendemos a consultar archivos de app/web.config y modificar ellos para satisfacer nuestras necesidades. Esto lleva a muchos problemas ya que de vez en cuando alguien revisará su propia configuración o perderá la configuración personalizada al obtener la última versión de tfs.

Mi pregunta es: ¿cómo lidias con situaciones como esta? ¿O no tienes este problema en absoluto?

Answer 1

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

Answer 2

¿Qué le parece ignorar el archivo, por lo que nunca se registra? Me he encontrado con un problema similar y he agregado web.config a la lista de ignorar en Subversion.

En TFS, sin embargo, es un poco más difícil, ver this post sobre cómo hacerlo.

Answer 3

Una forma de hacerlo es tener un sistema tokenizado y utilizar un script de rake para cambiar los valores.

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

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

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

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

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

Answer 4

En su fuente Web.config uso de otros archivos

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

Mantener el web.config en el control de versiones y no hacerlo por ConnectionStrings.config. Ahora todos los desarrolladores tienen un archivo para la cadena de conexión.

Puede hacer esto para todas las configuraciones que dependen del local.

Answer 5

Ignore los archivos y tenga Commom_Web.Config y Common_App.Config. Utilizar 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.

Answer 6

Usamos un sistema que combina varias de las respuestas existentes en esta página, más dibuja en this suggestion by Scott Hanselman.

En resumen, lo que hicimos fue tener un app.config/web.config común, y tener la mayoría de las configuraciones específicas en archivos individuales, como se sugiere en otras respuestas aquí. p.ej. para nuestra configuración SMTP, la aplicación.config contiene

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

Este archivo es de 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, esa no es la historia donde termina la historia. ¿Qué hay de los nuevos desarrolladores o una nueva instalación de origen? La mayor parte de la configuración ya no está en control de fuente, y es complicado construir manualmente todos los archivos .config que necesitan. Prefiero tener una fuente que compile al menos de manera inmediata.

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

Aún así, no es realmente ninguna utilidad para el desarrollador, ya que a Visual Studio sólo son archivos de texto sin sentido. De ahí que el archivo por lotes, copy_default_config.bat, se encarga de la creación de un conjunto inicial de archivos .config 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 guión está segura re-ejecutable, en el que los desarrolladores que ya tienen su .config los archivos no los sobrescribirán. Por lo tanto, uno podría concebiblemente ejecutar este archivo por lotes como un evento previo a la construcción. Los valores en los archivos .default pueden no ser exactamente correctos para una nueva instalación, pero son un punto de partida razonable.

En última instancia lo que cada desarrollador termina con una carpeta de archivos de configuración que se ve algo como esto:

Puede parecer un poco complicado, pero es sin duda preferible a la molestia de los desarrolladores pisando los dedos de los pies del otro.

Answer 7

Tenemos el mismo problema y lo que estamos haciendo es

• Comprobar en el web.config con los valores testserver/producción
• desarrollador va a Windows Explorer y cambiar el modo de sólo lectura del archivo
• Edite la configuración para adaptarla a su entorno.
• El registro en la web.config ocurre solo cuando los valores de implementación cambian o cualquier entrada de configuración se agrega o elimina.
• Esto necesita una buena cantidad de comentarios para cada entrada de configuración, ya que necesita ser cambiado cada dev

Answer 8

Suponiendo que usted está utilizando Visual Studio, ¿por qué no utilizar diferentes configuraciones de solución? Por ejemplo: puede tener una configuración de depuración que utiliza Web.config.debug y una configuración de liberación que utiliza Web.config.release. Web.config.debug debe tener algo como

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

con el archivo Standard_Name_For_Config.config que gots todos los ajustes de desarrollador personales, mientras que el Web.config.release siempre tiene la configuración de producción. Puede almacenar las configuraciones predeterminadas en alguna carpeta controlada por fuente y hacer que un nuevo usuario las tome desde allí.

Answer 9

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

1) Editar manualmente el archivo de aplicación web .csproj para añadir un objetivo AfterBuild así:

<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 objetivo se transformará el archivo Web.config correspondiente al desarrollador actual conectado - de ahí la variable $(USERNAME) -, con el archivo correspondiente creado en 1). Reemplazará el Web.config local solo si el contenido ha cambiado (para evitar el reinicio) en cada compilación, incluso si el Web.config local está controlado por código fuente, es por eso que el OverwriteReadOnlyFiles está establecido en True. Este punto, de hecho, es discutible.

2) Cree un archivo denominado Web.[developer windows login].config para cada desarrollador en el proyecto. (Por ejemplo, en las siguientes capturas de pantalla que tengo dos desarrolladores nombrados smo y smo2):

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

Cada uno de estos archivos representa una transformación para aplicar al archivo principal Web.Config. La sintaxis de transformación se describe aquí: Web.config Transformation Syntax for Web Application Project Deployment. Reutilizamos esta genial tarea de transformación de archivos Xml que viene de fábrica con Visual Studio. El propósito de esta tarea es fusionar elementos Xml y atributos en lugar de sobrescribir todo el archivo.

Por ejemplo, aquí es una muestra web.[dev login].config que cambia una cadena de conexión llamado '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, esta solución no es perfecta porque:

• después de la construcción, los desarrolladores pueden tener un diferente nivel local Web.Config que en el sistema de control de origen
• pueden tener que forzar la escritura local al conseguir un nuevo Web.Config del directorio sys control de código fuente tem
• los desarrolladores no deberían verificar/en el web.config principal. Debería reservarse para pocas personas.

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

Se podría tomar un enfoque similar para los archivos App.config (no para la web) pero no proporcioné más detalles.