¿Cómo maneja los archivos .config de .NET para aplicaciones grandes?

Question

Supongamos que una aplicación compuesta de gran tamaño se basa en varios componentes básicos empaquetados en sus propios ensamblajes: (lectura de base de datos, manejadores de protocolo, etc.). Para algunas implementaciones, esto puede incluir más de 20 ensamblajes. Cada uno de estos ensamblajes tiene configuraciones o información de configuración. A nuestro equipo le gusta el editor de configuraciones VS (¡y el código fácil de usar que genera!), Y la distinción entre aplicación y usuario satisface la mayoría de nuestras necesidades.

PERO ....

Es muy tedioso para copiar & pegar las muchas secciones de configuración en .xml de nuestra aplicación. Además, para componentes compartidos que tienden a tener configuraciones similares en todas las aplicaciones, esto significa que necesitamos mantener configuraciones duplicadas en múltiples archivos .config.

EntLib de Microsoft resuelve este problema con una herramienta externa para generar el archivo .config monstruo, pero esto se siente klunky también.

¿Qué técnicas utiliza para manejar grandes archivos de .NET .config con las secciones de varios ensamblados compartidos? Algún tipo de mecanismo de inclusión? Lectores de configuración personalizada?

Seguimiento:

de Will answer era exactamente lo que quería llegar, y se ve elegante para planas secciones de pares clave/valor. ¿Hay alguna manera de combinar este enfoque con custom configuration sections?

Gracias también por las sugerencias sobre el manejo de diferentes .configs para diferentes tipos de generación. Eso también es bastante útil.

de Dave

Answer 1

Se utiliza un archivo de configuración maestro que apunta a otros archivos de configuración. Here's an example of how to do this.

---

En el caso de las podredumbres de enlace, lo que se hace es especificar el configSource para una sección de configuración particular. Esto le permite definir esa sección en particular dentro de un archivo separado.

<pages configSource="pages.config"/> 

lo que implica que existe un archivo llamado "pages.config" en el mismo directorio que contiene todo el árbol <pages /> nodo.

Answer 2

Hemos creado una clase que actúa como AssemblySettingsConfig ConfigurationManager, pero carga un .config para cada conjunto individual. Entonces, la aplicación tiene .config, y las DLL a las que hace referencia tienen sus propios archivos .config. Ha funcionado bien hasta ahora.

Answer 3

Una forma excelente de administrar grandes conjuntos de configuración es crear secciones de configuración personalizadas. Phil Haack discute esta muy bien en este artículo Custom configuration sections in 3 easy steps

Answer 4

Mi método preferido es utilizar MSBuild, si hace clic en un proyecto y haga clic en 'descarga' una nueva opción de menú pop-up que dice 'editar'. Seleccione eso y abrirá el archivo del proyecto para que pueda editarlo, desplácese hacia abajo hasta que encuentre una sección comentada que se llama "AfterBuild".

A continuación, puede añadir algo como:

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

Esta sustituirá a la configuración de aplicaciones con uno llamado [Lanzamiento | depuración] app.exe.config. Entonces puede mantener configuraciones separadas según cómo se construya el proyecto.

Pero una opción rápida y sucia (si no desea jugar con msbuild) es simplemente mantener los archivos de configuración separados y luego definir cuál de ellos desea incluir, por ejemplo:

<appSettings configSource="Config\appSettingsDebug.config"/> 
<roleManager configSource="Config\roleManagerDebug.config"/> 

Y si usted está haciendo una aplicación asp.net, microsoft proporciona una gran utilidad llamada "Proyectos de Desarrollo de web" que le permitirá gestionar todo esto con facilidad, click here

Answer 5

Establecer configuraciones de construcción para cada uno de su entorno de despliegue/pruebas y use archivos de configuración separados basados ​​en cada configuración de compilación.

ScottGu tiene a nice post acerca de esto y funciona muy bien. La única peculiaridad que tenemos es que tenemos que asegurarnos de que los archivos de configuración (web.config) estén desprotegidos para su edición desde TFS antes de cada compilación para que puedan copiarse.