Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

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:

image

Et dans ce cas là la sortie de la compilation devient un peu vide:

image

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:

image

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.

 

image

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:

image

 

Nous allons simplement créer un fichier .target qui contient un “PropertyGroup” avec la propriété “DebugType” à “pdbonly”:

image

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:

image

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

Publié lundi 9 mai 2011 09:00 par Miiitch
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 :

Commentaires

# re: Bien connaître le fonctionnement des fichiers projets C# et VB.Net pour mieux contrôler la sortie des builds – Episode 1

Je n'entends pas souvent parler des MsBuildCommunityTasks. Je trouve ce projet trés interéssant - de mon côté pour l'interopérabilité de différents outils, tel subversion (injection du numéro de révision dans l'assembly.info par exemple).

Tu en penses quoi de ton côté ?

lundi 9 mai 2011 14:23 by Graveen

# re: Bien connaître le fonctionnement des fichiers projets C# et VB.Net pour mieux contrôler la sortie des builds – Episode 1

En effet, voilà une méthode bien plus élégante que l'habituel check-out de projet puis modification.

Le problème de départ est bien sûr le fait qu'un développeur ait enlevé la génération des symboles qui, même si ils sont moins utiles en .NET qu'en C++ ou autre techno native, doivent TOUJOURS etre compilés en même temps que leur dll/exe. Honni soit qui oublie :)

jeudi 12 mai 2011 23:30 by Julien Crozon
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- [VBA] Manipuler un SQL Server sans risque par Blog de Jérémy Jeanson le 06-13-2015, 11:48

- Témoignage sur le rôle d’architecte logiciel par Blog de Jérémy Jeanson le 06-13-2015, 11:34

- NCrafts : Machine learning the F# way par Aurélien GALTIER le 06-04-2015, 11:22

- Configuration de Workflow Manager 1.0 pour SharePoint 2013 et ses soucis. par The Mit's Blog le 06-01-2015, 18:04

- TFS 2013 : Migration d’une ferme TFS 2005 vers 2013 sans Upgrade par Blog Technique de Romelard Fabrice le 06-01-2015, 11:22

- Iconographie mobile par CrazyHT Blog le 06-01-2015, 07:56

- [WCF] Forcer des réponses JSon, même pour des requêtes XML par Blog de Jérémy Jeanson le 05-30-2015, 14:55

- [MVC] Plusieurs verbes pour une seule méthode du controller par Blog de Jérémy Jeanson le 05-29-2015, 14:08

- SPS Paris 2015 – Back from MS Ignite par Le blog de Patrick [MVP Office 365] le 05-26-2015, 16:04

- Windows 10 IOT– exploitez vos capteurs en tout genre ! par Blog de Daniel TIZON [daniel] le 05-26-2015, 08:06