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

- Office 365: Script PowerShell pour assigner des droits Full Control à un groupe défini par Blog Technique de Romelard Fabrice le 04-30-2017, 09:22

- SharePoint 20XX: Script PowerShell pour exporter en CSV toutes les listes d’une ferme pour auditer le contenu avant migration par Blog Technique de Romelard Fabrice le 03-28-2017, 17:53

- Les pièges de l’installation de Visual Studio 2017 par Blog de Jérémy Jeanson le 03-24-2017, 13:05

- UWP or not UWP sur Visual Studio 2015 ? par Blog de Jérémy Jeanson le 03-08-2017, 19:12

- Désinstallation de .net Core RC1 Update 1 ou SDK de Core 1 Preview 2 par Blog de Jérémy Jeanson le 03-07-2017, 19:29

- Office 365: Ajouter un utilisateur ou groupe dans la liste des Site collection Administrator d’un site SharePoint Online via PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-24-2017, 18:52

- Office 365: Comment créer une document library qui utilise les ContentTypeHub avec PowerShell et CSOM par Blog Technique de Romelard Fabrice le 02-22-2017, 17:06

- [TFS] Supprimer en masse les dépendances à SQL Enterprise ou Developer avant de procéder à une migration par Blog de Jérémy Jeanson le 02-20-2017, 20:30

- Office 365: Attention au volume utilisé par les fichiers de Thèmes de SharePoint Online par Blog Technique de Romelard Fabrice le 02-07-2017, 18:19

- [SCVMM] Supprimer une machine bloquée par Blog de Jérémy Jeanson le 01-31-2017, 21:22