Gestion des fichiers Web.Config complexes entre les environnements de déploiement

Question

Personne ne sait de toute bonne outils/utilitaires de gestion Web.Les fichiers de configuration entre les différents build/environnements de déploiement?

Par exemple, j'ai un WCF projet dans le développement, je ne veux pas activer SSL, mais je ne veux elle a permis à la production. Je veux les différents paramètres de journalisation, les différentes DB chaînes de connexion, erreur de manipulation, les différents chemins d'accès aux fichiers... Même certains différents de l'Unité cadre de liaisons (fil jusqu'se moque de tests unitaires plutôt que des objets réels pour le déploiement).

Le maintien des copies individuelles du Web.La Config est une douleur, car l'ajout d'un nouveau service sur le web signifie que l'édition de plusieurs fichiers et de synchronisation entre eux.

J'ai aussi remarqué que si vous le fumier avec le Web.Config trop par la main, Visual Studio va s'étouffer si vous essayez d'utiliser la fonction "ajouter un élément" de l'assistant, par exemple, ajouter un nouveau Service Web WCF, car il a à modifier le site Web.Config pour ajouter le point de terminaison,et ne peut pas l'analyser. Donc je dois faire attention de ne pas invalider le site Web existant.Config.

J'ai également pensé simplement à l'aide de quelques regex pour effectuer des remplacements et de la simple construction d'un nouveau site Web.Config en pré-commande créer. Cela semble être la meilleure option si loin...

D'autres idées? Il semble que ce devrait être un problème très commun, puisque le Web.Config devrait probablement jamais être le même entre le développement et les déploiements de production.

---

Mise à jour:

J'ai décidé d'écrire rapidement une application console qui va prendre tous les fichiers xml dans un répertoire donné et de les fusionner en un seul, et seulement inclure certains fichiers en fonction du nom.

Donc, je peux faire dans un répertoire:

WebConfig_All

<configuration>
  <configSections>
    ...
  </configSections>
  <system.web>
    ...
  </system.web>
</configuration>

connectionStrings_Debug

<configuration>
  <connectionStrings>
    <add name="connstr" connectionString="...dev..." />
  </connectionStrings>
</configuration>

connectionStrings_Release

<configuration>
  <connectionStrings>
    <add name="connstr" connectionString="...prod..." />
  </connectionStrings>
</configuration>

Exécutez ensuite mon outil de ligne de commande, et de les passer dans la configuration (Debug, Release, personnalisé...) Et il va fusionner tous les fichiers qui se terminent par "Tous" ou "<configuration>".

Alors maintenant, j'ai 80% de mon Web.Config dans un seul WebConfig_All fichier,un nd de 20% personnalisé des trucs sous la forme de plusieurs fichiers par la configuration de build. Je peux alors faire fonctionner mon outil de ligne de commande comme un pré-construction tâche dans VisualStudio, ou de NAnt, ou partout où je veux...

J'ai aussi fait mon XML fusion logique assez bon pour gérer ce genre de choses:

<x>
  <y a="1">
    <z a="1"/>
  </y>
</x>

fusionner avec

<x>
  <y a="1">
    <z a="2"/>
  </y>
  <y a="2"/>
</x>

résultats:

<x>
  <y a="1">
    <z a="1"/>
    <z a="2"/>
  </y>
  <y a="2"/>
</x>

Bon à la recherche de si loin... :)

---

Suivi:

Ce sujet est un peu vieux maintenant, donc je tenais à préciser que VisualStudio 2010 a une fonction pour faire web.config transformations intégrées: http://msdn.microsoft.com/en-us/vstudio/Video/ff801895

Bien sûr, typique de Microsoft de la mode de la seule mise en œuvre de toute fonctionnalité de 50% de la sorte, il ne fonctionne que pour les projets de sites web à l'aide de déployer. Il y a un plugin pour permettre des transformations dans d'autres projets, trouve ici: http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx

Vous pouvez également utiliser un outil comme BuildMaster pour gérer les fichiers de config (avec les constructions, les tests, les DB scripts, etc...)

Answer 1

Nous avons divisé toute la région des paramètres spécifiques dans leur propre fichier de configuration. En vertu de la racine de l'application web, nous créons un dossier config et le lieu de la région des paramètres spécifiques. Donc que ce soit des fichiers vivent sous la racine de config aura ramassé.

notre site web.config ressemble à quelque chose comme:

.
.
.
<appSettings configSource="config\appSettings.config"/>
<nlog configSource="config\nlog.config"/>
<applicationSettings>
	<MyApp.UI.Properties.Settings configSource="config\Settings.APGUI.config"/>
	<MyApp.BusinessServices.Properties.Settings configSource="config\Settings.Business.config"/>
	<MyApp.Auditing.Properties.Settings configSource="config\Settings.Auditing.config"/>
</applicationSettings>
.
.
.

Donc, si nous mettons en place à la libération de la région de l'outil de génération va juste avoir une action de remplacer les fichiers dans la racine de config avec les fichiers de la région appropriée du dossier. La structure du fichier ressemble à quelque chose comme:

AJOUTÉE: C'est la source de contrôle de la structure semble, que le déploiement de l'application aurait juste la config dir avec pas de sous-dossiers ou des cours de

\Root
   web.config    
   \Config    
       appsettings.config    
       services.config    
       logging.config    
       \release    
          appsettings.config    
          services.config    
          logging.config    
       \debug
          appsettings.config    
          services.config    
          logging.config

Il est très propre et pris en charge par un de génération automatique d'outil(copier/remplacer des fichiers). Le côté sympa affecter, c'est que les développeurs peuvent créer des saveurs différentes et de les garder sous contrôle de code source, sans affecter la "vraie" configs.

Answer 2

Vous pouvez utiliser Build Events pour gérer vos configurations Web. Hanselman a un bon article à ce sujet.

Fondamentalement, vous avez tous vos différents web.configs dans la solution que vous créez ensuite (certains) nouveaux types de construction. Selon le type de construction que vous exécutez, le fichier web.config est copié sur celui référencé!

Answer 3

Vous voulez la tâche XmlMassUpdate dans MSBuildCommunityTasks (fait ce que vous essayez de faire avec votre application console xml)

http://msbuildtasks.tigris.org/

l'utiliser comme ça

   <XmlMassUpdate Condition=" '@(ConfigTemplateFile)'!='' And '@(ConfigSubstitutionsFile)'!=''"
    ContentFile="@(ConfigTemplateFile)"
    SubstitutionsFile="@(ConfigSubstitutionsFile)"
    MergedFile="@(ConfigFile)"
    ContentRoot="/configuration"
    SubstitutionsRoot="/configuration/substitutions/$(Configuration)"/>
 

Answer 4

J'utilise la méthode expliquée par Scott Hanselman (il l'explique beaucoup mieux que je ne peux le reproduire alors suivez le lien :)) Cela a bien fonctionné pour moi ...

Answer 5

J'utilise cet outil: xmlpreprocess

nous gérons des fichiers de «propriétés» distincts pour chaque environnement fusionné par le script de déploiement.