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

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

En bref, nous avons eu un app.config / web.config commun et la plupart des parameters spécifiques dans des fichiers individuels, comme le suggèrent d’autres réponses ici. Par exemple, pour nos parameters SMTP, le fichier app.config contient

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

Ce n’est pas tout à fait où l’histoire se termine bien. Qu’en est-il des nouveaux développeurs ou d’une nouvelle installation source? L’essentiel 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 une source qui sera au moins compilée 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 fichiers .config.default . Un nouvel arbre source ressemble donc à ceci:

Pourtant, pas vraiment utile pour le développeur, car pour Visual Studio, ce ne sont que des fichiers texte sans signification. Par conséquent, le fichier de commandes, 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 est ré-exécutable en toute sécurité, car les développeurs qui ont déjà leurs fichiers .config ne les auront pas écrasés. Par conséquent, on peut imaginer d’exécuter ce fichier de commandes en tant qu’é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 sharepoint 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 nettement préférable aux problèmes des développeurs qui se marchent les uns sur les autres.

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

1) Modifiez manuellement le fichier .csproj de votre application Web pour append une cible AfterBuild comme ceci:

   ...    
 
    

Cette cible transformera le fichier Web.config correspondant au développeur actuellement connecté – d’où la variable $(USERNAME) -, avec le fichier correspondant créé en 1). Il remplacera le Web.config local uniquement si le contenu a été modifié (pour éviter le redémarrage) à chaque génération, même si le fichier Web.config local est contrôlé par une source, c’est pourquoi OverwriteReadOnlyFiles est défini sur True. 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 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 cool qui est prête à l’emploi avec Visual Studio. Le but de cette tâche est de fusionner les éléments et atsortingbuts Xml au lieu de remplacer tout le fichier.

Par exemple, voici un exemple web.[dev login].config qui modifie une chaîne de connexion nommée «MyDB», quel que soit le rest du fichier Web.config:

Maintenant, cette solution n’est pas parfaite car:

• après la construction, les développeurs peuvent avoir un Web.Config différent de celui du 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 fichier web.config principal. Il devrait être réservé à quelques personnes.

Mais au moins, il vous suffit de gérer un fichier web.config principal plus un fichier de transformation par développeur.

Une approche similaire pourrait être adoptée pour les fichiers App.config (pas Web), mais je n’ai pas développé davantage.

Dans votre Web.config, utilisez la source des autres fichiers

   ...  

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

Vous pouvez le faire pour tous les parameters dépendant de la région.

Nous utilisons machine.config pour éviter les différences dans web.config entre les environnements.

Ignorer les fichiers et avoir un Commom_Web.Config et Common_App.Config. Utilisation d’un serveur de génération d’continuous integration avec des tâches de génération qui renomment ces deux noms normaux afin que le serveur de génération puisse faire son travail.

Que diriez-vous d’ignorer le fichier afin qu’il ne soit jamais archivé? J’ai rencontré un problème similaire et j’ai ajouté web.config à la liste des ignorés de Subversion.

Dans TFS cependant, c’est un peu plus difficile, consultez cet article sur la façon de le faire.

Une des façons de faire consiste à utiliser un système tokenisé et à utiliser un script rake pour modifier les valeurs.

Une méthode plus rudimentaire pourrait être d’avoir un lien vers un fichier AppSettings.config pour tous les AppSettings de votre site web.config (similaire aux connexions), c.-à-d.

Ensuite, un dossier avec chacun de vos développeurs a une version dans un sous-dossier (par exemple / _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 apscopes à ces fichiers (sauf si vous les marquez). Si vous gardez le fichier AppSettings.config hors du contrôle des sources et que vous ne cochez que les dossiers individuels des développeurs (tous), ils seront alors obligés de copier le fichier correct.

Je préfère la tokenisation mais peut être plus difficile à mettre en place si cela ne doit être qu’une solution rapide.

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

• Archiver le fichier web.config avec les valeurs de serveur de test / de production
• Le développeur passe à l’explorateur Windows et modifie le mode lecture seule du fichier
• Modifiez la configuration pour l’adapter à leur environnement.
• L’archivage dans 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 dev

En supposant que vous utilisez Visual Studio, pourquoi ne pas utiliser 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

avec le fichier Standard_Name_For_Config.config qui regroupe tous les parameters personnels du développeur, tandis que Web.config.release a toujours les parameters de production. Vous pouvez stocker les configurations par défaut dans un dossier contrôlé par une source et faire en sorte qu’un nouvel utilisateur les en prenne.