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

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

Désormais, 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érents points de terminaison WCF , etc.)

Pour le moment, nous avons tendance à extraire 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 lors de l'obtention de la dernière version de TFS .

Comment gérez-vous des situations comme celle-ci? Ou n'avez-vous pas du tout ce problème?

Nous utilisons un système qui combine plusieurs des réponses existantes sur cette page, en plus de s'inspirer de cette suggestion de Scott Hanselman .

En bref, ce que nous avons fait, c'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 fichier est sous contrôle de code source. Cependant, les fichiers individuels, comme celui-ci, ne 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>

Ce n'est pas tout à fait là que l'histoire se termine. Qu'en est-il des nouveaux développeurs ou d'une nouvelle installation source? La majeure partie de la configuration n'est plus sous contrôle de code source et il est difficile de créer manuellement tous les fichiers .config dont ils ont besoin. Je préfère avoir des sources qui seront au moins compilées dès la sortie de la boîte.

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

Pourtant, cela ne sert vraiment à rien pour le développeur, car pour Visual Studio, ce ne sont que des fichiers texte sans signification. Par conséquent, 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, il est possible d'exécuter ce fichier de commandes en tant qu'événement de pré-construction. Les valeurs des fichiers .default peuvent ne pas être exactement correctes pour une nouvelle installation, mais elles constituent un point de départ raisonnable.

En fin de compte, chaque développeur se retrouve avec un dossier de fichiers de configuration qui ressemble à ceci:

Cela peut sembler un peu compliqué, mais c'est certainement préférable aux tracas des développeurs qui se marchent sur les pieds.

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. Désormais, tous les développeurs ont un fichier pour la chaîne de connexion.

Vous pouvez le faire pour tous les paramètres qui dépendent du local.

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

1) Modifiez manuellement le fichier .csproj de votre application Web pour ajouter une AfterBuildcible 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 actuel connecté - d'où la $(USERNAME)variable -, avec le fichier correspondant créé en 1). Il remplacera le Web.config local uniquement 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 le OverwriteReadOnlyFilesest défini sur True. Ce point est en fait discutable.

2) Créez un fichier nommé Web.[developer windows login].configpour 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épendants du fichier Web.config principal car nous voulons pouvoir les extraire individuellement.

Chacun de ce fichier représente une transformation à appliquer au fichier Web.Config principal. La syntaxe de transformation est décrite ici: Syntaxe de transformation Web.config pour le déploiement de projet d'application Web . Nous réutilisons cette tâche de transformation de fichier Xml géniale qui est prête à l'emploi avec Visual Studio. Le but de cette tâche est de fusionner des éléments et des attributs XML au lieu d'écraser le fichier entier.

Par exemple, voici un exemple web.[dev login].configqui modifie une chaîne de connexion nommée «MyDB», quel que soit le 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>

Or, 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 de source
• ils peuvent avoir à forcer l'écriture locale lors de l'obtention d'un nouveau Web.Config à partir du système de contrôle de source
• les développeurs ne doivent pas extraire / dans le web.config principal. Il devrait être réservé à quelques personnes.

Mais au moins, vous n'avez qu'à gérer un fichier web.config principal unique plus un 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 développé davantage.

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

Pourquoi ne pas ignorer le fichier pour qu'il ne soit jamais archivé? J'ai rencontré un problème similaire et j'ai ajouté web.config à la liste des ignorés dans Subversion.

Dans TFS cependant, c'est un peu plus difficile, consultez cet article pour savoir comment le faire.

Une façon de faire face est d'avoir un système tokenisé et d'utiliser un script rake pour changer les valeurs.

Une méthode plus rudimentaire pourrait être d'avoir un lien vers un fichier AppSettings.config pour tous les AppSettings dans votre web.config (similaire avec les connexions) ie

<appSettings configSource="_configs/AppSettings.config" />

Ensuite, ayez un dossier avec chacun de vos développeurs avoir une version dans un sous-dossier (ie / _configs / dave /). Ensuite, lorsqu'un développeur travaille sur son propre code, il copie du sous-dossier à la racine du dossier lié.

Vous devrez vous assurer de communiquer les modifications apportées à ces fichiers (sauf si vous effectuez un jeton). Si vous gardez le fichier AppSettings.config hors du contrôle de code source et archivez uniquement les dossiers individuels des développeurs (tous), ils seront obligés de copier le bon.

Je préfère la tokenisation, mais cela peut être plus difficile à démarrer si cela est uniquement destiné à être une solution rapide.

Ignorez les fichiers et disposez d'un Commom_Web.Config et Common_App.Config. Utilisation d'un serveur de build d'intégration continue avec des tâches de build qui renomme ces deux en noms normaux afin que le serveur de build puisse faire son travail.

Nous avons le même problème et ce que nous faisons est

• Archivez le web.config avec les valeurs de testerver / production
• Le développeur accède à l'explorateur Windows et change le mode lecture seule du fichier
• Modifiez la configuration en fonction de leur environnement.
• L'enregistrement dans le fichier web.config se produit uniquement lorsque les valeurs de déploiement changent ou qu'une entrée de configuration est ajoutée ou supprimée.
• Cela nécessite une bonne quantité de commentaires pour chaque entrée de configuration car il doit être modifié par chaque développeur

En supposant que vous utilisez Visual Studio, pourquoi n'utilisez-vous pas différentes configurations de solution? Par exemple: vous pouvez avoir une configuration Debug qui utilise Web.config.debug et une configuration Release qui utilise Web.config.release. Web.config.debug devrait avoir quelque chose comme

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config"> 

avec le fichier Standard_Name_For_Config.config qui récupère tous les paramètres personnels du développeur, tandis que Web.config.release a toujours les paramètres de production. Vous pouvez stocker les configurations par défaut dans un dossier contrôlé par la source et faire en sorte qu'un nouvel utilisateur les prenne à partir de là.