Comment gérez-vous les fichiers .NET app.config pour les applications volumineuses?

Question

Supposons qu'une grande application composite repose sur plusieurs composants de base regroupés dans leurs propres assemblys: (lecture de base de données, gestionnaires de protocole, etc.). Pour certains déploiements, cela peut inclure plus de 20 assemblys. Chacun de ces assemblys contient des paramètres ou des informations de configuration. Notre équipe a tendance à aimer l'éditeur de paramètres VS (et le code facile à utiliser qu'il génère!), Et la distinction entre application et utilisateur répond à la plupart de nos besoins.

MAIS ....

Il est très fastidieux de copier & coller les nombreuses sections de configuration dans le .xml de notre application. En outre, pour les composants partagés qui ont tendance à avoir des configurations similaires entre les applications, cela signifie que nous devons conserver les paramètres dupliqués dans plusieurs fichiers .config.

Microsoft EntLib résout ce problème avec un outil externe pour générer le fichier .config monstre, mais cela se sent aussi klunky. Quelles techniques utilisez-vous pour gérer de gros fichiers .NET .config avec des sections provenant de plusieurs assemblys partagés? Une sorte de mécanisme d'inclusion? Lecteurs de configuration personnalisés?

FOLLOWUP:

Will answer était exactement ce que je voulais en venir, et une allure élégante pour les sections de paires clé/valeur plat. Existe-t-il un moyen de combiner cette approche avec custom configuration sections?

Merci également pour les suggestions sur la gestion de différents .configs pour différentes cibles de construction. C'est aussi très utile.

Dave

Answer 1

Vous utilisez un fichier de configuration maître qui pointe vers d'autres fichiers de configuration. Here's an example of how to do this.

---

En cas le lien pourrit, ce que vous faites est de spécifier la configSource pour une section de configuration particulière. Cela vous permet de définir cette section particulière dans un fichier distinct.

<pages configSource="pages.config"/> 

ce qui implique qu'il ya un fichier appelé « pages.config » dans le même répertoire contenant l'ensemble des nœuds <pages />.

Answer 2

Nous avons créé une classe AssemblySettingsConfig qui agit comme ConfigurationManager, mais charge un fichier .config pour chaque assembly individuel. L'application a donc un fichier .config et toutes les DLL auxquelles il fait référence ont leurs propres fichiers .config. A bien fonctionné jusqu'à présent.

Answer 3

Une excellente façon de gérer de grands ensembles de configuration consiste à créer des sections de configuration personnalisées. Phil Haack parle très bien de cet article Custom configuration sections in 3 easy steps

Answer 4

Ma méthode préférée est d'utiliser MSBuild, si vous faites un clic droit sur un projet et cliquez sur 'décharger' une nouvelle option de menu apparaîtra qui dit 'éditer'. Sélectionnez-le et il ouvrira le fichier de projet afin que vous puissiez le modifier, faites défiler jusqu'à ce que vous trouviez une section commentée appelée "AfterBuild".

Vous pouvez ensuite ajouter quelque chose comme:

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

Cela remplacera la configuration de l'application avec un nommé [Release | Debug] app.exe.config. Vous pouvez donc conserver des configurations séparées en fonction de la manière dont le projet est construit.

Mais une option rapide et sale (si vous ne voulez pas jouer avec msbuild) est de maintenir simplement les fichiers de configuration séparés puis définir celui que vous voulez inclure, comme ceci:

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

Et Si vous faites une application asp.net, Microsoft fournit un excellent utilitaire appelé "Web Deployment Projects" qui vous permettra de gérer tout cela facilement, click here

Answer 5

Configurer des configurations de construction pour chacun de votre environnement de déploiement/test et utiliser des fichiers de configuration distincts basés sur chaque configuration de construction.

ScottGu a a nice post à ce sujet et cela fonctionne très bien. La seule bizarrerie que nous avons est que nous devons nous assurer que les fichiers de configuration (web.config) sont vérifiés par TFS avant chaque compilation afin qu'ils puissent être copiés.