Meilleure approche pour la configuration de plusieurs applications .Net

Question

Nous avons une suite d'applications .Net 3.5 interconnectées. Certains sont des sites Web, d'autres sont des services Web et certains sont des applications Windows. Chaque application a actuellement son propre fichier de configuration (app.config ou web.config), et actuellement il y a des clés dupliquées dans les fichiers de configuration (qui sont pour l'instant synchronisés manuellement) car plusieurs applications requièrent la même valeur de configuration. De plus, cette suite d'applications est déployée sur divers envrionemnts (dev, test, live, etc.)

Quelle est la meilleure approche pour gérer la configuration de ces multiples applications à partir d'une seule source de configuration, afin que les valeurs de configuration puissent être partagées entre plusieurs applications si nécessaire? Nous aimerions également avoir des configs séparées pour chaque environnement (ainsi, lors du déploiement, vous ne devez pas modifier manuellement certaines valeurs de configuration spécifiques à l'environnement, telles que les chaînes de conversion), mais vous ne souhaitez pas conserver plusieurs configurations importantes. fichiers (un pour chaque environnement) en gardant cette synchronisation lors de l'ajout de nouvelles clés de configuration va s'avérer gênant.

Answer 1

Nous utilisons des modèles de fichiers tels que MyApp.config.template et MyWeb.config.template propriétés NAnt pour les bits qui sont différents entre les environnements. Ainsi, le fichier de modèle peut sembler un peu comme ceci:

<MyAppConfig> 
    <DbConnString>${DbConnString}</DbConnString> 
    <WebServiceUri uri="${WebServiceUri}" /> 
</MyAppConfig> 

Au cours d'une construction que nous générons tous les configs pour les différents environnements en boucle juste à travers chaque environnement dans un script NAnt, en changeant la valeur des propriétés NAnt $ { DbConnString} et $ {WebServiceUri} pour chaque environnement (en fait, ils sont tous définis dans un seul fichier avec des sections pour chaque environnement), et faire une copie NAnt avec l'option de développer les propriétés activées.

Il a fallu un peu de temps pour se mettre en place, mais il nous a redonné au moins dix fois plus de temps avec la perte de temps avec différentes versions de fichiers de configuration.

Answer 2

Visual Studio dispose d'une fonctionnalité relativement obscure qui vous permet d'ajouter des éléments existants sous forme de liens, ce qui devrait vous permettre d'obtenir ce que vous recherchez. Découvrez Derik Whittaker's post sur ce sujet pour plus de détails. Visual Studio devrait vraiment rendre cette option plus visible. Personne ne pense vraiment à cliquer sur cette petite flèche à côté du bouton "Ajouter".

Answer 3

Examinez le cadre de prisme du groupe de modèles et de pratiques de Microsoft.

Answer 4

Vous pouvez diviser App.config en plusieurs fichiers de configuration. Vous venez de spécifier le nom du fichier qui contient la section de configuration.

changement app.config:

<SomeConfigSection> 
    <SettingA/> 
    <SettingB/> 
</SomeConfigSection> 
<OtherSection> 
    <SettingX/> 
</OtherSection> 

Dans app.config et SomeSetting.xml:

<SomeConfigSection file="SomeSetting.xml" /> 
<OtherSection file="Other.xml" /> 

Où SomeSetting.xml contient:

Maintenant, vous pouvez composer votre app.config à partir de différents fichiers de section avec une sorte de script de construction ou de déploiement. .: par exemple

if debug copy SomeSettingDebug.xml deploydir/SomeSetting.xml 
if MySql copy OtherSectionMySql.xml deploydir/OtherSetting.xml 

Answer 5

Ces 2 questions pourraient vous aider: Utilizing machine.config et Managing app.config for large projects