Fichiers de configuration contenant des paramètres spécifiques à l'environnement

Question

Dans mon organisation, nous avons plusieurs environnements (Dev, QA, Stage, Prod, Disaster Recovery) et je voudrais que mes fichiers app/web.config ne contiennent aucun détail spécifique à l'environnement dans les URI, les connexions chaînes, etc. Mon approche préférée serait d'effectuer une substitution au moment de l'exécution, par exemple Au lieu de cela:

<endpoint address="http://MyDevWebServer/SomeService" binding="basicHttpBinding"...

Je préférerais avoir quelque chose comme ceci: lire des classes je contrôle

<endpoint address="http://{Env:WebServerName}/SomeService" binding="basicHttpBinding"...

est simple pour les paramètres de configuration sur (juste fournir une wrapper qui exécute des substituts {Env: WebServerName} avec le nom de serveur réel pour cet environnement) mais je souhaite également que cette substitution ait lieu lorsque des paramètres sont lus à partir de classes sur lesquelles je n'ai aucun contrôle (par exemple WCF, NHibernate etc.). Est-ce que quelqu'un sait d'une manière d'injecter ce genre de logique de substitution. Je suppose qu'une approche AOP pourrait être possible, mais je n'ai pas personnellement beaucoup d'expérience avec les frameworks AOP.

Answer 1

Vous devriez être en mesure de le faire en dérivant une classe personnalisée de ApplicationSettingsBase qui fournit cette substitution.

Je recommande de lire sur le Application Settings Architecture. Il décrit le processus de création de votre propre architecture de paramètres, y compris la définition de votre propre gestionnaire, qui peut être lu à partir de n'importe quelle source ou effectuer d'autres tâches dans le processus.

Answer 2

Une approche consiste à utiliser ConfigSource pour une section de configuration (appSettings, connectionStrings, etc.). Voir http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource.aspx pour plus d'informations à ce sujet. Ainsi, le fichier web/app.config peut contenir les informations de base et les paramètres d'environnement uniques peuvent être définis dans le fichier pour cet environnement.

Answer 3

Nous avons un script nant post-construction qui utilise XPath pour identifier et remplacer les valeurs spécifiques à l'environnement, en fonction de l'environnement que nous ciblons. Toutes les valeurs de configuration sont pour l'environnement de développement par défaut. Cela ajoute un court délai au processus de construction, mais s'est avéré être une solution très robuste dans la pratique - c'est-à-dire sans paramètres d'environnement falsifiés ou croisés.

Answer 4

Nous avons déménagé notre cadre à la base de données et n'ont pas dû faire face à ce depuis, voir here.

Answer 5

Je suis d'accord competely que ce genre de substitution serait souhaitable, et requested this feature on Microsoft Connect.

Pas beaucoup d'intérêt de Microsoft si :(

Answer 6

Alors que vous essayez de trouver un moyen de faire une substitution d'exécution, je vous suggère qu'une substitution accumulation de temps serait une meilleure solution dans ce cas. Par exemple, nous utilisons la tâche nante xmlpoke pour remplacer les valeurs de configuration lors de la construction. Vous pouvez également essayer de remplacer la section web.config dans web deployment projects ou tâche XmlMassUpdate MSBuild tâches communautaires (example).