Comment gérez-vous plusieurs fichiers web.config pour plusieurs environnements?

Question

La façon dont je gère actuellement c'est en ayant plusieurs fichiers de configuration tels que:

web.config 
web.Prod.config 
web.QA.config 
web.Dev.config 

Lorsque le projet se déploie dans les différents environnements, je renomme simplement le fichier correspondant avec les paramètres corrects.

Quelqu'un at-il des suggestions pour mieux gérer cela?

EDIT: Voici quelques-unes des choses qui changent dans chaque config:

• WCF Endpoint Client urls et sécurité
• configs Base de données personnalisés
• chaînes de connexion de session
• paramètres de log4net

Answer 1

Scott Gu avait un article sur cette fois. La solution qu'il a présentée consistait à utiliser un événement de pré-construction pour copier la configuration correcte en place en fonction de la configuration de construction choisie.J'ai aussi remarqué qu'il y a déjà un question similaire sur SO.

Answer 2

Cela dépend vraiment de la différence entre l'environnement s qui vous oblige à utiliser différents fichiers web.config. Pouvez-vous donner plus d'informations sur les raisons pour lesquelles chaque environnement a besoin d'un environnement différent?

Answer 3

La façon dont nous l'avons fait est de passer outre la section AppSettings:

<appSettings file="../AppSettingsOverride.config"> 
    <add key="key" value="override" />  
    ... 
</appSettings> 

Cela ne fonctionne que pour la section appSettings et est donc utile que dans une certaine mesure. Je serais très intéressé par des solutions plus robustes.

Modifier

Juste regardé ceci: http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/

VS2010 a transforme config qui ont l'air assez impressionnant, devrait faire plusieurs configurations un jeu d'enfant complète.

Answer 4

Dans Visual Studio, je crée des événements de génération xcopy et stocke tous les fichiers de configuration dans un dossier/config. Vous n'avez besoin que d'un seul événement pour toutes les configurations si vous nommez vos fichiers après la configuration de la construction: par exemple, écrasez web.config avec /config/web.$(Configuration).config

Answer 5

Nous avons quelques solutions (pas toutes fait avec web.config mais la même idée)

1. Nous incluons plusieurs fichiers de configuration dans le déploiement packagé. Pendant l'installation, nous spécifions l'environnement sur lequel nous installons.
2. Migrez tous les paramètres spécifiques à l'environnement vers le serveur de base de données pour cet environnement. WebServer fournit son environnement lors de la demande du nom du serveur
3. Fournit plusieurs paramètres (1 par environnement) et utilise différents paramètres de demande de code.
4. Combinaison de 2 et 3 (Remplacer une partie des paramètres en fonction de l'environnement - par exemple le nom du serveur d'applications)

Answer 6

Grâce à la plupart des logiciels de gestion de versions différents (subversion, git, etc.), vous pouvez ignorer des fichiers spécifiques.

Ainsi, la subversion, je dois:

configure.template.php - Ce fichier est versionné et contient des données de configuration, tels que basés sur des modèles configure.php de DSN vide - Ce fichier est ignoré, de sorte que les modifications ne sont pas suivies.

Dans la subversion, la façon de le faire est:

svn pe svn: ignore. Il va ouvrir votre éditeur, puis vous tapez configure.php

Enregistrer, quitter, vérifier vos modifications, et vous êtes prêt à partir.

Answer 7

Ma méthode préférée pour y remédier est l'attribut configSource. Certes, je ne l'utilise que sur un seul élément (<connectionStrings>) mais il permet d'échanger facilement différents segments d'un web.config (ce que je fais pendant l'installation via un projet WebSetup).

Answer 8

J'utilise aussi le web.DEV.config, web.TEST.config, web.PROD.config etc.

Je trouve cette façon la plus facile, plus simple et directe si vos projets ne sont pas complexe. Je n'aime pas rendre les choses plus compliquées que nécessaire. Cependant, j'ai utilisé NAnt et je pense que cela fonctionne bien pour cela. Vous pouvez configurer des builds pour vos différents environnements. NAnt prend quelques lectures pour apprendre à l'utiliser mais c'est assez flexible.

http://aspnet.4guysfromrolla.com/articles/120104-1.aspx

http://nant.sourceforge.net/

Je l'ai utilisé avec CruiseControl.net et NUnit pour effectuer tous les jours automatique construit avec la validation des tests unitaires et ont pensé qu'ils ont bien travaillé ensemble.

Answer 9

Les transformations semblent vraiment utiles pour cela. Vous pouvez remplacer certaines sections par des règles différentes.

http://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx