L’utilisation du fichier app.config dans les applications .net est tout à fait commun. Que ce soit pour stocker des variables “personnalisées” (appSettings, sections spécifiques) ou des variables utilisées par les différents outils/framework (chaînes de connexions aux bases de données, bindings WCF, …), on en retrouve dans une grande majorité de projets .net.

Il y a également une question récurrente qui vient avec l’utilisation de l’app.config : Comment faire pour avoir un fichier pour mon poste de dev, et un fichier pour la prod, simplement ?

Il y a désormais une solution simple et efficace avec SlowCheetah – XML Transforms, un plugin Visual Studio 2010 gratuit, développé par un Microsoftee, qui permet de gérer simplement des XML différents pour chacune de vos configurations.

Go Cheetaa !

Une fois le plugin installé, ouvrez votre projet avec un fichier app.config (qui peut donc déjà exister ;), le menu contextuel laisse apparaitre une nouvelle option Add Transform.

Après avoir accepté l’avertissement, vous verrez votre fichier App.config, plus un fichier par configuration existante App.Configuration.config.

A ce stade, si vous ouvrez les fichiers App.Debug.config ou App.Release.config, leur contenu peut vous décevoir. En effet, ils sont (quasi) vides. Ce qu’il faut comprendre, c’est que ces fichiers utilisent en réalité la syntaxe de transformation déjà existante des projets web.config. En d’autres termes, vos fichiers App.configuration.config sont des fichiers de transformations XML (XDT). Ils vous permettent de transformer des éléments précis du fichier XML app.config. Voyons cela avec un exemple. Nous avons ici un fichier assez classique, avec deux settings et une chaîne de connexion.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <appSettings>
    <add key="appName" value="Mon logiciel" />
    <add key="version"  value="1.2.3.0"/>
  </appSettings>
<connectionStrings>
  <add name="BeehiveEntities" 
       connectionString="metadata=res://*/MonModele.csdl|res://*/MonModele.ssdl|res://*/MonModele.msl;provider=System.Data.SqlClient;provider connection string="data source=.;initial catalog=MaBase;integrated security=True;App=MonAppli"" providerName="System.Data.EntityClient" />
</connectionStrings></configuration>

Pour la version debug, nous voulons changer le nom du logiciel et faire apparaître une nouvelle clée pour activer le débug (ceci est pour l’exemple d’ajout de balises, il y a d’autres méthodes pour gérer le “debug” ;)). Nous allons donc reproduire les “parties” – à savoir hiérarchie de balises et la balise elle-même- de ce que nous voulons modifier. Pour que la magie opère, nous devons rajouter quelques attributs supplémentaires (en jaune) permettant de déterminer le type d’opération que nous souhaitons réaliser (remplacer, insérer, supprimer), et la manière de trouver quelle ligne correspond dans le fichier d’origine (via des attributs, une requête XPath, …).

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings>
    <add key="appName" value="Mon Logiciel - Bewise Internal" xdt:Transform="Replace" xdt:Locator="Match(key)"/>
    <add key="debug" value="true" xdt:Transform="Insert" />
  </appSettings>
</configuration>

Il ne vous reste plus qu’à faire F5 pour voir le résultat….ou de faire un clic droit !

L’option Preview Transform va réaliser l’opération de transformation et va vous afficher le résultat en parallèle avec le fichier App.config d’origine.

Un de plus ?

Si par la suite, vous ajoutez des configurations à votre projet, il vous suffit de recommencer l’opération et les nouveaux fichiers seront ajoutés automatiquement, sans écraser vos fichiers existants.

Ca fonctionne avec tous les projets ?

Presque ! Les projets Web ne fonctionnement pas tel quel, mais ils supportent déjà cette fonctionnalité nativement. Mes tests ont montrés que les types de projets suivants fonctionnent nativement (en C#):

• Console
• Windows Forms
• WPF
• VSTO (testé sur plugin Outlook 2010)
• Service Windows
• Solutions Sharepoint 2010
• XNA (Windows uniquement)
• Addin Visual Studio
• Projets de test VS
• Azure Worker Role

Et le travail en équipe / l’intégration continue ?

L’une des parties cool de ce projet est d’utiliser des fonctionnalités standard des outils, en l’occurence des targets MSBuild. Cela veut dire que, pour le coût de quelques modifications de votre fichier de projet et de la copie de quelques fichiers dans votre repository, cela peut fonctionner à la fois pour votre équipe – et quelque soit votre contrôleur de source (TFS, SVN, Git, ..) – et pour l’intégration continue (avec TFS, je n’ai pas testé avec d’autres outils tels que TeamCity).

Pour cela, il vous faudra :

• Copier le contenu du répertoire $(LOCALAPPDATA)MicrosoftMSBuildSlowCheetahv1 dans votre solution,
• Modifier les fichiers projets concernés pour modifier la ligne ci-dessus avec le nouvel emplacement.

Il ne reste plus qu’à espérer que tout ce fonctionnement sera intégré à Visual Studio vNext.