Fichiers app.config/web.config spécifiques aux développeurs dans Visual Studio

Question

Nous avons plusieurs projets .NET dans lesquels nous stockons certains paramètres dans des fichiers de configuration.

Maintenant, chaque développeur aura ses propres fichiers de configuration qui diffèrent un peu (différentes chaînes de connexion pour se connecter aux bases de données locales, différentes WCF points d'arrivée, etc.)

Pour l'instant, nous avons tendance à consulter les fichiers app/web.config et à les modifier en fonction de nos besoins.

Cela conduit à de nombreux problèmes car, de temps en temps, quelqu'un vérifie ses propres paramètres ou perd sa configuration personnalisée lorsqu'il obtient la dernière version de l'UE. TFS .

Comment faites-vous face à ce genre de situation ? Ou n'avez-vous pas du tout ce problème ?

Answer 1

Nous utilisons un système qui combine plusieurs des réponses existantes sur cette page, et qui s'appuie sur les éléments suivants cette suggestion de Scott Hanselman .

En bref, ce que nous avons fait est d'avoir un app.config / web.config commun, et d'avoir la plupart des paramètres spécifiques dans des fichiers individuels, comme suggéré par d'autres réponses ici. par exemple, pour nos paramètres SMTP, l'app.config contient

<system.net>
  <mailSettings>
    <smtp configSource="config\smtp.config" />
  </mailSettings>
</system.net>

Ce dossier est dans le contrôle de source. Cependant, les fichiers individuels, comme celui-ci, ne le sont pas :

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
  <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

Mais l'histoire ne s'arrête pas là. Qu'en est-il des nouveaux développeurs, ou d'une nouvelle installation des sources ? La majeure partie de la configuration n'est plus dans le contrôle de source, et c'est une douleur de construire manuellement tous les fichiers .config dont ils ont besoin. Je préfère avoir des sources qui compilent au moins dès la sortie de la boîte.

Par conséquent, nous conservons une version des fichiers .config dans le contrôle de source, nommée .config.default des dossiers. Un arbre source frais ressemble donc à ceci :

Pourtant, ils ne sont pas vraiment utiles au développeur, car pour Visual Studio, ce ne sont que des fichiers texte sans intérêt. D'où le fichier batch, copy_default_config.bat se charge de créer un ensemble initial de fichiers .config à partir des fichiers .config.default :

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

Le script peut être ré-exécuté en toute sécurité, en ce sens que les développeurs qui ont déjà leurs fichiers .config ne les verront pas écrasés. Par conséquent, on pourrait concevoir d'exécuter ce fichier batch comme un événement de pré-construction. Les valeurs dans les fichiers .default peuvent ne pas être exactement correctes pour une nouvelle installation, mais elles constituent un point de départ raisonnable.

Au final, chaque développeur se retrouve avec un dossier de fichiers de configuration qui ressemble à quelque chose comme ceci :

Cela peut sembler un peu alambiqué, mais c'est certainement préférable à l'ennui des développeurs qui se marchent sur les pieds.

Answer 2

Dans votre Web.config, utilisez la source d'autres fichiers

<configuration>
    <connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

Gardez le web.config dans le contrôle de version et ne le faites pas pour ConnectionStrings.config. Maintenant, tous les développeurs ont un seul fichier pour la chaîne de connexion.

Vous pouvez faire de même pour tous les paramètres qui dépendent de l'environnement local.

Answer 3

Voici une solution pour les fichiers web.config et Visual Studio 2010 :

1) Modifiez manuellement le fichier .csproj de votre application Web afin d'y ajouter un fichier de type AfterBuild Une cible comme celle-ci :

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

Cette cible transformera le fichier Web.config correspondant au développeur actuellement connecté - d'où la mention $(USERNAME) variable -, avec le fichier correspondant créé en 1). Il ne remplacera le Web.config local que si le contenu a changé (pour éviter le redémarrage) à chaque build, même si le Web.config local est contrôlé par la source, c'est pourquoi il y a l'option OverwriteReadOnlyFiles est réglé sur Vrai. Ce point est en fait discutable.

2) Créez un fichier nommé Web.[developer windows login].config pour chaque développeur du projet. (par exemple, dans les captures d'écran suivantes, j'ai deux développeurs nommés smo et smo2) :

Ces fichiers (1 par développeur) peuvent/doivent être contrôlés par la source. Ils ne doivent pas être marqués comme dépendant du Web.config principal car nous voulons pouvoir les vérifier individuellement.

Chacun de ces fichiers représente une transformation à appliquer au fichier Web.Config principal. La syntaxe de la transformation est décrite ici : Syntaxe de transformation Web.config pour le déploiement de projets d'applications Web . Nous réutilisons cette tâche de transformation de fichier Xml qui est livrée prête à l'emploi avec Visual Studio. Le but de cette tâche est fusionner éléments et attributs Xml au lieu d'écraser l'ensemble du fichier.

Par exemple, voici un exemple web.[dev login].config qui modifie une chaîne de connexion appelée "MyDB", indépendamment du reste du fichier Web.config :

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

Maintenant, cette solution n'est pas parfaite car :

• après la construction, les développeurs peuvent avoir un Web.Config différent localement que dans le système de contrôle des sources.
• ils peuvent être amenés à forcer l'écriture locale lors de l'obtention d'un nouveau Web.Config à partir du système de contrôle des sources.
• Les développeurs ne devraient pas vérifier/ouvrir le web.config principal. Cela devrait être réservé à quelques personnes.

Mais au moins, vous ne devez maintenir qu'un seul web.config principal et un seul fichier de transformation par développeur.

Une approche similaire pourrait être adoptée pour les fichiers App.config (et non web) mais je n'ai pas approfondi.

Answer 4

Nous utilisons machine.config pour éviter d'avoir des différences dans web.config entre les environnements.

Answer 5

Ignorer les fichiers et avoir un Commom_Web.Config et un Common_App.Config. Utiliser un serveur de construction à intégration continue avec des tâches de construction qui renomment ces deux fichiers en noms normaux afin que le serveur de construction puisse faire son travail.