Bien connaître le fonctionnement des fichiers projets C# et VB.Net pour mieux contrôler la sortie des builds – Episode 1
L’intérêt d’une build est de fournit un binaire compilé toujours avec le même environement, mais la build utilise quand même la configuration qui se trouve dans les fichiers projets. Un exemple: rien n’empêche un développeur de supprimer en mode Release la génération des symboles de debuggage:
Et dans ce cas là la sortie de la compilation devient un peu vide:
Si il n’y a pas de validation à la compilation de la build de la présence des fichiers de symboles, en cas de problème en production, nous n’aurions rien pour nous aider. C’est pour cela qu’il est très important de redefinir au moment de la build la façon dont le logiciel est compilé. Il y a toujours moyen de modifier avant la compilation la configuration du projet, mais je préfère faire croire à MSBuild que la configuration à compiler est la mienne plutot que de modifier des fichiers.
Avant tout, qu’il y a-t-il dans les fichiers .csproj et .vbproj? Déjà, ce sont des fichiers lisibles par MSBuild. D’ailleurs vous pouvez lancer une compilation pour l’importe quel fichier de projet (ou solution) via la ligne de commande de msbuild. Pour simplifier, on peut assimiler le .*proj à l’ADN du projet.
A la fin du projet, une ligne est très importante:
C’est cette ligne qui va injecter les “targets” MSBuild qui vont compiler le projet. La cible finale, le chef d’orchestre de la compilation, est chargé après par les fichiers spécifiques à chaque langage. Ce fichier est Microsoft.Common.targets.La connaissance de Microsoft.Common.targets est indispensable si l’on veut maitriser la sortie de la build.
Seule la partie bleue est spécifique au projet.
Comment va-t-on faire pour changer le fonctionnement de la compilation? Microsoft.Common.targets contient des points d’extensions qui vont nous permettre de modifier le comportement de la build:
- Un point d’extension avant le chargement des “targets” communes de compilation: ici il va être possible de changer la configuration du projet,
- Un point d’extension après le chargement des “targets” communes de compilation: ici on va pouvoir redefinir des “targets” de compilation pour ajouter nos éléments.
Pour simplifier, ces points d’extensions injectent tout simplement des scripts MSBuild via des <Import /> dans le script du projet. Dans cet exemple, nous allons donc nous comporter comme un virus en injectant notre ADN de compilation: la configuration de la génération des symboles de debug. Voici la configuration en mode Release de notre projet:
Nous allons simplement créer un fichier .target qui contient un “PropertyGroup” avec la propriété “DebugType” à “pdbonly”:
Et nous lançons tout cela via la ligne de commande suivante:
msbuild MonApp.sln /p:CustomBeforeMicrosoftCommonTargets=D:\TempDev\MonApp\ConfigOverride.targets /p:Configuration=Release
Comme attendu les symboles sont maintenant disponibles:
Pour l’instant rien n’est vraiment automatisé, mais nous verrons dans un prochain billet comment mettre tout cela en place dans une build. Pour information, sur TFS 2008 un autre fichier MSBuild est bon à connaître (par coeur): celui de TeamBuild. Dans TFS 2010 il a été remplacé par un workflow en XAML.
End Of Line
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
