C'est quoi un Ingénieur d'Intégration Continue

L’intégration continue est un concept qui se base sur l’analogie avec une usine automatisée. Sauf qu’au lieu de construire des voitures, on construit un logiciel. Un logiciel est modifié sans cesse et pour sécuriser son processus de fabrication, il faut automatiser le plus possible sa fabrication.

En 2013, j'écrivais déjà un article sur l'intégration continue : Outils d'Intégration Continue

Attention l'intégration continue s'entend souvent sur multiplateformes une partie des développements viennent de Windows et peut être qu'une autre partie vient de Linux, il faudra évoquer CMake.

Pour découvrir rapidement CMake :

Alexandre Laurent - Développez.com - Utiliser CMake pour compiler un projet

Etape par étape, je vais détailler les outils correspondants au métier de l'Ingénieur d'intégration continue. Dans les équipes de développement une personnes est dédiée à l'intégration continue. C'est ce qui différencie un développement artisanal d'un véritable développement professionnel. 

Alors quelles sont les spécificités de ce métier ? Quelles sont les nouveautés de ces dernières années.

Ingénieur d'intégration continue définition de poste

Je débute par une définition de poste voilà ce que je propose :

Collaborer avec les experts techniques R&D (architectes logiciel et experts métier) et les utilisateurs (équipes de qualification des produits) pour comprendre les exigences métier et identifier les solutions d’intégration et déploiement automatisés et de validation automatique de nos produits logiciels.

Il s'agit bien sûr d'une très grosse société au sein d'une très grosse équipe. Là on se rend compte que l'intégration continue n'a pas pu être mise en œuvre, il faut donc un facilitateur.

Et l'on donne l'outil Jenkins

Nous y voilà, nous avons une parfaite connaissance d'MSBuild on y ajoute les Outils d'Intégration Continue et au dessus de tout ça l'outil Jenkins va nous permettre de faire quoi ?

Jenkins Documentation Use-cases - C/C++

Jenkins Définition

Jenkins est un serveur d'automatisation open source autonome qui peut être utilisé pour automatiser toutes sortes de tâches liées à la création, au test, à la livraison ou au déploiement de logiciels.

Jenkins Installation

Jenkins est une application web à laquelle on accède par localhost une fois installée.

Jenkins - Getting started with the Guided Tour

La suite consiste à créer des pipeline des canaux de livraison continue. L'objectif de Jenkins est de pouvoir enchaîner les différentes étapes pour construire tester et déployer l'application.

Vous maîtrisez un outil comme Jenkins vous êtes un Ingénieur d'Intégration Continue.

Vous avez maintenant tout le loisir de vous former à Jenkins. Je voudrais aborder une notion importante de Jenkins c'est Blue Ocean dit comme ça c'est flou mais Blue Ocean vient se mettre au dessus de Jenkins et permet de repenser l'expérience utilisateur de Jenkins. Blue Ocean est un éditeur de pipeline.

En suite, je pense faire un tour du côté de ce site :

Continuous Integration with MSBuild and Jenkins – Part 1

Et puis un petit retour sur la doc Jenkins et l'intégration de MSBuild Plugin pour l'intégration continue sur plateforme Windows :

Jenkins - MSBuild Plugin

Car MSBuild cela je connais bien :

MSBuild - Outils d'intégration continue

Donc un Ingénieur d'intégration continue ce serait quelqu'un qui maîtrise aussi bien MSBuild que Jenkins. Ce blog est donc l'outil pour devenir un Ingénieur d'Intégration Continue.

Outils d'intégration continue

Quand on a pratiqué l'intégration continue entièrement intégrée avec Team Foundation Server, on est un peu désarçonné par l'ensemble de tous les outils qui peuvent être utilisés afin de mettre en place une stratégie d'intégration continue avec d'autres chaînes de développement que TFS. 

Cet article est là pour faire un petit récapitulatif de ce qu'est l'intégration continue.

Team Foundation Server

Les principes d'intégration continue permettent de distinguer un développement artisanal d'un développement industriel ou développement maîtrisé de façon professionnelle.+

En intégration continue, vous avez forcément un serveur dédiée sur lequel le produit logiciel est déployé afin de faire une vérification complète du produit avant de déployer sur une cible finale, ce n'est pas le cas dans le cadre d'un développement artisanal.

Les Principes de l'Intégration Continue

• le code source est partagé et versionné dans un gestionnaire de code source (un référentiel ou repository unique)
• les développeurs intègrent (commit ou checkin) leur code le plus souvent possible (chaque jour par exemple)
• des tests unitaires sont développés et des tests d'intégration permettent de valider l'application sur un serveur d'intégration (ou serveur de build)

La mise en place de ces principes permet de :

• tester immédiatement les unités modifiées et leur compatibilité entre elles
• découvrir immédiatement des codes manquants ou incompatibles
• les problèmes d'intégration sont réparés pour éviter les problèmes de dernière minute
• une version est toujours disponible pour un test une démonstration ou une distribution

Qu'est ce que l'intégration continue sur le site de So@t

Intégration continue des bases de données : RedGate avec SQL Toolbelt comparaison de schémas de base de données. BD SQL Server ou Oracle.

Team Foundation Server pour :
Gestion de Projet
Gestion de prérequis
Versionnement de code source
Gestion de cas de test
Automatisation de build
Génération de rapports

Configuration du serveur TFS : Team Server Foundation en pas à pas

Sur le Blog de Julien Carnelos : L'intégration continue Open Source en .NET

Principe : Tout ce qui peut-être automatisé doit l'être.
Contrôle de codes sources : SVN (Subversion)
Tests Unitaires : NUnit
Compilation et Build : NAnt
Contrôle de construction : CruiseControl.NET et CCTray

Pour aller plus loin : Mise en place d'outils d'analyse de codes sources de génération de métriques. Terminer le Build NAnt par la génération d'un package d'installation prêt pour la livraison. L’envoi d'un email de notification à un client ou mieux à une équipe de QA (Assurance Qualité).

Je me propose de recopier ici quelques bonnes phrases du blog de J.Carnelos car les liens cassent ...

On oppose généralement l’aspect industriel du développement à l’artisanal. Pour mieux saisir la signification de ce terme, je vous propose une petite histoire :

Après quatre mois de développement, c’est le grand jour de la livraison. Georges, après avoir testé une dernière fois que son code compile, décide de déployer la version finale du site Intranet de la mairie. La démarche est maîtrisée puisque cela fait maintenant une vingtaine de fois qu’il a répété l’opération. Comme à chaque fois, il commence par demander à son collègue sur quels fichiers il a travaillé. La liste connue, il récupère par le réseau ces fichiers, puis tente de compiler le projet. Chance, tout compile.

La suite est plus délicate, Georges doit se connecter à distance au serveur, migrer la base de données et insérer les données mis à jour. Vient ensuite la partie copie des fichiers sur le serveur et redémarrage du serveur. A ce moment, si tout va bien, le site devrait être mis à jour. Malheureusement, au premier test, impossible de se logger.

Si cette scène vous rappelle quelque chose, pas d’inquiétude car c’est courant et aujourd’hui de nombreuses sociétés fonctionnent dans ce mode de gestion. Mais l’industrialisation et l’automatisation sont maintenant un but plus facile que jamais à atteindre grâce à de nombreux outils. Preuve en est également l’implication de Microsoft sur le thème « Gestion du cycle de vie logiciel » et la fourniture d’une offre complète avec la suite Team System et son serveur Team Foundation Server.

Néanmoins pour des raisons de simplicité, nous nous attacherons ici à présenter les concepts de l’intégration continue à l’aide uniquement d’outils open-source.

Concept

Schéma d'une chaine d'intégration continue

L’intégration continue est un concept qui se base sur l’analogie avec une usine automatisée. Sauf qu’au lieu de construire des voitures, on construit un logiciel. Cette « usine » est construite sur enchaînement suivant :

1. Un développeur travaille en local. Lorsque ses modifications sont terminées, il archive son code sur un serveur gestionnaire de sources.
2. A la détection d’un changement (ou suivant une règle temporelle paramétrée), le serveur d’intégration récupère la dernière version des sources et déclenche la construction (« build ») de la solution.
3. En étape facultative mais intéressante, il est possible d’appliquer des métriques et des tests sur la solution et d’en générer des rapports
4. Enfin, la solution et le bilan de la construction sont déployés sur un serveur de résultat accessible à l’équipe projet. Dans le cas d’un sous traitance, ce portail peut aussi être mis à la disposition du client pour qu’il puisse constater l’avancement du projet. (Particulièrement utile dans le cadre d’une démarche agile).

Documentation des codes sources

On ne crée pas de bons codes sources sans bonne documentation.

NDoc : Open Source Documenter, Générateur de documentation pour .NET

Sous TFS : SharePoint, oups ce n'est pas aisé d'utiliser cet outil que je trouve un peu archaïque

Outils d'analyse des codes sources

Fédérer une équipe autour d'un développement passe par le partage d'un certain nombre de bonnes pratiques, on appelait cela les coding guidelines aujourd'hui des outils permettent d'automatiser cette tâche en analysant les codes sources.

StyleCop : analyse syntaxique du code source C# sur le CodePlex : StyleCop

StyleCop provides value by enforcing a common set of style rules for C# code.

ReSharper de JetBrains : payant

Un outil d'analyse de code dans Visual Studio Express 2012

FxCop : curieux on note Framework 2.0, semble ne plus exister

Contrôle de codes sources, gestionnaire de versions

C'est un serveur, un endroit centralisé pour récupérer les codes sources créés par les développeurs, un outil permettant de versionner. Permet de résoudre les conflits de réaliser un merge entre plusieurs développements.

Outils :

TFS

SVN ou Subversion

CVS

Git

Perforce 

Tests Unitaires

Il existe MSTest mais il semble que cet outils de tests unitaires soit maintenant supplanté par NUnit ...

MSTest vs. NUnit with Visual Studio 2010 & TDD

NUnit vs xUnit parmi les modules de Tests Unitaires lequel choisir ?

Sur la plateforme .NET : NUnit

Sur le site du code project, rapidement comprendre NUnit : Unit Testing Using NUnit

NUnit permet d'écrire des tests unitaires du genre :

Assert.AreEqual(expected, actual)

NUnit permet l'utilisation de Mock Objects (simulateur d'objets)

A priori le projet NUnit n'est plus hébergé sur source forge mais Ici

Serveur d'intégration ou serveur de builds

C'est un élément clef de l'intégration continue souvent manquant dans les organisation "amateurs".

Les opérations à effectuer grâce aux outils de builds sont :

Nettoyer le répertoire de sortie (les binaires)

Compiler le code source

Exécuter les tests unitaires

Exécuter le programme

Mais aussi :

zip de fichier

transfert ftp

redémarrage de serveur web

En partant des sources, effectuer toute la livraison jusqu’à l’étape déployable (ou même déployé).

Intégration continue avec Team Foundation Server
MSBuild

NAnt qui possède l'avantage d'être multi-plateforme, s'exécute en ligne de commande et prend en paramètre un fichier XML qui décrit les différentes étapes pour emmener le code source dans l'état prêt à l'exécution.

CruiseControl.NET

TeamCity : de JetBrains

For .NET :

Building Visual Studio solutions; native support for MSBuild, Powershell or NAnt
Code analysis for C#, VB.NET, XAML, and many other languages powered by ReSharper
Testing with .NET testing frameworks, including: NUnit, MSTest, MSpec, xUnit and all Gallio-based frameworks
Code coverage with dotCover, NCover or PartCover
Best-in-class NuGet support

Je compléterai plus tard ... vous avez des suggestions d'amélioration et de complétion de cet article, n'hésitez pas à le commenter. Vous avez compris l'intégration continue concerne toutes les phases de développement du logiciel et l'utilisation des outils qui permettent d'automatiser tout ce qui peut l'être.

To Be Continued

Moteur de Build Microsoft : MSBuild Engine (4)

Je souhaite réaliser la programmation d'une Tâche MSBuild. En lisant MSDN, il est parfois difficile de passer de la théorie à la pratique. Ici on va donc être pratique et réussir la programmation et l'exécution d'une tâche MSBuild.

Programmation d'une tâche MSBuild

On a vu dans MSBuild Engine (1) que l'on doit utiliser les directives using :
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;

Ces DLL se trouvent dans :
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319


En ajoutant dans le projet leurs références, un petit souci survient, des icônes en jaune :

Using MSBuild in .NET Framework 4.0 Client Profile

Afin d'utiliser ces deux DLL, il faut configurer le .NET Framework 4.0 dans les propriétés du projet :

Using MSBuild in .NET Framework 4.0

Choisissant le .NET Framework 4, le problème est résolut :

Using MSBuild choix du .NET Framework 4.0

L'utilisation de ces librairies n'est bien entendu pas comprise dans le "Client Profile". Il n'y a aucune raison d'exécuter une build sur un client.

Je peux maintenant ajouter une Class dans mon projet MyBuildProject :

using System;

using Microsoft.Build.Utilities;

namespace MyBuildProject

{

    public class TaskMSBuild : Task

    {

        public override bool Execute()

        {

            Console.WriteLine("TaskMSBuild Executed ...");

            return true;

        }

    }

}

Dans le .csproj, je rajoute :

<UsingTask TaskName="TaskMSBuild" 

             AssemblyFile="E:\WPF Presentation Sample\MyBuildProject\MyBuildProject\bin\Debug\MyBuildProject.exe" 

             TaskFactory="ClassName" />

  <Target Name="MyTargetTaskMSBuild">

      <TaskMSBuild />

  </Target>

Etant donné que ma tâche est directement dans mon projet j'ai donc la propriéte "AssemblyFile" settée avec mon .exe. Le tag "<TaskMSBuild />" semble ne pas trop être apprécié par l'interpréteur ...

J'ai comme l'impression que cela ne va pas fonctionner :

Programmation d'une Tâche MSBuild dans la fenêtre console commande de Visual Studio

Il y a plein de rouge ! Heureusement MSBuild est là pour m'aider et corriger mes erreurs.

Exécution d'une tâche MSBuild réussie

Finalement dans mon fichier projet, je garde :

  <UsingTask TaskName="TaskMSBuild" 

             AssemblyFile="E:\WPF Presentation Sample\MyBuildProject\MyBuildProject\bin\Debug\MyBuildProject.exe" />

  <Target Name="MyTargetTaskMSBuild">

    <TaskMSBuild />

  </Target>

Et à l'exécution :

Programmation d'une Tâche MSBuild exécution réussie

J'ai bien une trace de l'exécution de ma tâche MSBuild : "TaskMSBuild Executed ...".

Download Sample Code

Requirements :
Visual Studio 2010

Moteur de Build Microsoft : MSBuild Engine (3)

Voyons un peu comment, à l'aide de Visual Studio et dans les propriétés du projet (.csproj) je peux insérer des événements. Et observons les impacts que cela à dans mon fichier projet le tout par rapport à la syntaxe MSBuild.

Pré-Build  et Post-Build Events

Je vais créer deux commande DisplayPreBuildEvent.cmd et DisplayPostBuildEvent.cmd que je vais déclencher dans les propriétés de mon projet :

DisplayPreBuildEvent.cmd

@echo OFF

echo ----------------------

echo ------ Pre BUILD Event

echo ----------------------

@echo ON

J'ouvre donc les propriétés de mon projet, bouton-droit, "Properties" :

MSBuild - Propriétés du projet

Dans l'onglet "Build Events" je colle le CALL aux deux commandes :

MSBuild - Build Events Call Commandes

J'appelle maintenant MSBuild depuis la console de commande Visual Studio, voici l'exécution que j'obtiens :

MSBuild - Exécution des Pré et Post Build Events

Mes deux commandes s'affichent bien. Ayant conservé la substitution des cibles MSBuild, je peux voir comment l'exécution de ces commandes s'insèrent dans le processus de génération.

Syntaxe MSBuild : Pré-build et Post-Build Events

Que s'est-il passé au niveau de mon fichier projet (.csproj) ?

En l'ouvrant, je constate l'insertion des deux lignes d'appelle à mes commande de post et de pré-build :

<PropertyGroup>

<PreBuildEvent>call "...\MyBuildProject\DisplayPreBuildEvent.cmd"</PreBuildEvent>

</PropertyGroup>

<PropertyGroup>

<PostBuildEvent>call "...\MyBuildProject\DisplayPostBuildEvent.cmd"</PostBuildEvent>

</PropertyGroup>

Voilà donc la syntaxe MSBuild de mon action effectuée dans Visual Studio.

Moteur de Build Microsoft : MSBuild Engine (2)

Allons un peu plus loin dans le langage MSBuild.

Précédemment dans ce blog

Modification du fichier projet .csproj

Lors de la création d'un projet avec Visual Studio effectivement pour pouvoir éditer le .csproj il faut décharger le projet ensuite avec bouton-droit sur le projet décharger vous pouvez choisir "Editer le fichier .csproj".

En bas de ce fichier, vous trouvez le début de la personnalisation du processe de Build et le code suivant :

<!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
      Other similar extension points exist, see Microsoft.Common.targets.
<Target Name="BeforeBuild">
</Target>
<Target Name="AfterBuild">
</Target>
-->

Pour utiliser ce code, il suffit de le décommenter.

Customisation de Visual Studio pour MSBuild

Pour travailler plus efficacement car il va me falloir décharcher et recharger sans cesse le projet MyBuildProject.csproj afin de le modifier. J'ai envie de me créer une barre de boutons perso avec les deux boutons "Unload Project" et "Relaod Project".

J'obtiens la barre suivante :

Visual Studio - MyCustomBar avec les boutons "Unload" et "Relaod"

Exécution d'une Target (cible) spécifique de Build

En ajoutant les lignes suivantes dans mon fichier .csproj :

  <Target Name="HelloWorld">
    <Message Text="Hello"></Message>
    <Message Text="World"></Message>
  </Target>

J'ai ajouter une cible spécifique nommée "HelloWorld". Pour l'exécuter, j'ouvre la console commande de Visual Studio :

Exécution de MSBuild dans la console Visual Studio

Vous obtenez le résultat de l'exécution de la commande MSBuild :

>msbuild myProject.csproj /t:HelloWorld

Résultat de l'exécution de MSBuild dans la console Visual Studio

Les lignes :

Hello
World

apparaissent dans la console.

Remarque : l'exécution de MSBuild dans la console Visual Studio est plus verbose (plus parlante) que dans Visual Studio où l'on obtient le résultat suivant :

------ Build started: Project: MyBuildProject, Configuration: Debug x86 ------
  MyBuildProject -> E:\WPF Presentation Sample\MyBuildProject\MyBuildProject\bin\Debug\MyBuildProject.exe
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

Je n'ai donc exécuté que la target spécifique "HelloWorld" grâce au commutateur /t

Substitution et exécution des cibles MSBuild

J'ajoute maintenant les lignes suivantes dans mon fichier .csproj :

  <Target Name="BeforeBuild">

    <Message Text="Message BeforeBuild"></Message>

  </Target>

  <Target Name="AfterBuild">

    <Message Text="Message AfterBuild"></Message>

  </Target>

Et je j'exécute la commande :

>msbuild

Remarque : Que l'on ajoute ou non le nom du fichier .csproj, le résultat de la commande est le même. En fait si un seul fichier .csproj existe dans le répertoire alors MSBuild le prend par défaut et s'il y a plusieurs fichiers .csproj dans le répertoire alors MSBuild sort en erreur :

MSBuild - Exécution de la commande >msbuild dans la console de commande Visual Studio

J'obtiens bien mes deux messages :

Message BeforeBuild

Message AfterBuild

En suite, je vous propose de lire une page sur le site MSDN :
Comment : étendre le processus de génération Visual Studio

On y croisera l'ensemble des cibles que l'on peut substituer sans risque.

Subsitution de toutes les cibles MSBuild

Voici donc l'ensemble des cibles que l'on peut substituer sans risque :

BeforeCompile, AfterCompile
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après que la compilation principale a eu lieu. La plupart des personnalisations sont faites dans l'une de ces deux cibles.
BeforeBuild, AfterBuild
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après toutes les autres tâches de la génération.
Remarque : Les cibles BeforeBuild et AfterBuild sont déjà définies dans les commentaires à la fin de la plupart des fichiers projet. Vous pouvez ainsi ajouter facilement des événements avant génération et après génération à votre fichier projet.
BeforeRebuild, AfterRebuild
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après l'appel de la fonctionnalité de régénération principale. L'ordre de l'exécution cible dans Microsoft.Common.targets est le suivant : BeforeRebuild, Clean, Build, puis AfterRebuild.
BeforeClean, AfterClean
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après l'appel de la fonctionnalité de nettoyage principale.
BeforePublish, AfterPublish
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après l'appel de la fonctionnalité d'édition principale.
BeforeResolveReference, AfterResolveReferences
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après la résolution des références d'assembly.
BeforeResGen, AfterResGen
Les tâches insérées dans l'une de ces cibles s'exécutent avant ou après la génération des ressources.

L'ensemble des cibles substituables se trouve dans les fichiers :
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets
C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets

Erreur de la documentation :
En ouvrant le fichier Microsoft.Common.targets du Framework 4.0, on s'aperçoit qu'il y a une erreur dans la documentation : BeforeResolveReference s'écrit comme AfterResolveReferences avec un "s".

Par curiosité j'ai créé un fichier .csproj avec l'ensemble de ces cibles, j'obtiens l'exécution de MSBuild suivante :

MSBuild - Exécution de toutes les cibles substituables

On s'aperçoit que dans ce cas, elles ne sont pas toutes exécutées et l'on découvre l'ordre d'exécution logique des cibles de MSBuild.

Moteur de Build Microsoft : MSBuild Engine (1)

MSBuild, est un outil de génération d'applications. Il utilise un schéma XML pour contrôler la génération de produits logiciels. Visual Studio utilise MSBuild mais MSBuild ne dépend pas de Visual Studio.

En appelant MSBuild sur un fichier projet ou solution, vous pouvez orchestrer ou générer des produits dans des environnements où Visual Studio n'est pas installé.

Dans les fichiers projets (.csproj) vous trouverez le code XML MSBuild qui s'exécute lorsque l'on génère l'application.

Ainsi vous pouvez modifier le système de génération et :

• Prétraitez les fichiers avant qu'ils atteignent le compilateur.
• Copiez les sorties de génération vers un autre emplacement.
• Créez les fichiers compressés les sorties de génération.
• Effectuez une étape de post-traitement. Par exemple, vous pouvez emboutir un assembly avec une version différente.

Exemple d'utilisation : Utiliser Visual Studio sur un ordinateur de développement pour écrire le code XML de MSBuild  à l'aide de l'IDE, puis transmettre ce code aux autres développeurs qui l'exécuteront en ligne de commande afin d'intégrer votre développement.

MSBuild est utilisé dans le cadre d'une stratégie d'intégration continue.

On trouve MSBuild.exe dans les répertoires :
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
C:\WINDOWS\Microsoft.NET\Framework\v3.5

Egalement avec l'installation du Framework 4.5

Allez plus loin Ici.

Procédure pas à pas d'utilisation de MSBuild

Création d'un projet MSBuild et examen du fichier projet

Vous créez un projet avec Visual Studio, en suite pour éditer le fichier .csproj vous devez "Décharger  le projet" puis en cliquant bouton droit vous pourrez éditer, modifier le fichier .csproj.

Les fichiers XML MSBuild ont un noeud racine : "Project"

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="4.0" DefaultTargets="Build"  xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

Notion de Tâche MSBuild

Une tâche est la plus petite unité de travaille (l'atome) d'une build.

Les tâches MSBuild fournissent du code exécuter pendant le processus de génération. Chaque tâche est implémentée dans une classe .NET qui dérive de l'interface ITask.

Une bibliothèque de tâches courantes est fournit avec MSBuild mais pour écrire vos propre tâche il y a deux approches :

• Implémentez l'interface ITask directement.
• Dérivez votre classe de la classe d'assistance, Task, qui est définie dans l'assembly Microsoft.Build.Utilities.dll. La tâche implémente ITask et fournit des implémentations par défaut de quelques membres ITask. En outre, la journalisation est plus facile.

Exemple code C# :

using System;

using Microsoft.Build.Framework;

using Microsoft.Build.Utilities;

namespace MyTasks

{

    public class SimpleTask : Task

    {

        public override bool Execute()

        {

            return true;

        }

    }

}

Le fichier projet qui exécute cette tâche :

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <Target Name="MyTarget">

        <SimpleTask />

    </Target>

</Project>

Allez plus loin Ici

Pour exécuter une tâche, MSBuild a besoin de mapper la tâche sur l'assembly qui contient son implémentation à l'aide de UsingTask.

<UsingTask TaskName="TaskName"

    AssemblyName = "AssemblyName" 

    TaskFactory = "ClassName"

    Condition="'String A'=='String B'" />

Notion de Cible MSBuild

Une cible est une séquence nommée de tâches.

Déclaration des cibles dans le fichier projet

<Target Name="Construct">

    <Csc Sources="@(Compile)" />

</Target>

Cibles prédéfinies :

<Target Name="AfterBuild" >
   <Message Text="First occurrence" />
</Target>
<Target Name="AfterBuild" >
   <Message Text="Second occurrence" /> 
</Target>

Dans ce cas uniquement la "Second Occurence" sera exécutée car MSBuild n'exécute qu'une fois une cible unique.

Ordre de génération des cibles

• Cibles initiales
• Cibles par défaut
• Première cible
• Dépendances cible
• BeforeTargets et AfterTargets (MSBuild 4.0)

Allez plus loin Ici.

Traitement par lots des cibles

Une cible peut avoir un attribut Outputs qui spécifie des métadonnées, dans ce cas, MSBuild exécute la cible une fois pour chaque valeur de métadonnées unique, en regroupant ou en "traitant par lot".

Exemple :

<ItemGroup>

    <Reference Include="System.Core">

      <RequiredTargetFramework>3.5</RequiredTargetFramework>

    </Reference>

    <Reference Include="System.Xml.Linq">

      <RequiredTargetFramework>3.5</RequiredTargetFramework>

    </Reference>

    <Reference Include="Microsoft.CSharp">

      <RequiredTargetFramework>4.0</RequiredTargetFramework>

    </Reference>

</ItemGroup>

<Target Name="AfterBuild"

    Outputs="%(Reference.RequiredTargetFramework)">

    <Message Text="Reference:

      @(Reference->'%(RequiredTargetFramework)')" />

</Target>

Donne à l'exécution :

   Reference: 3.5;3.5

   Reference: 4.0

Builds incrémentielles

Pour améliorer la vitesse de génération MSBuild utilise un mécanisme de build incrémentielle pour n'exécuter que les mises à jour. Un élément est considéré comme à jour si son fichier de sortie a la même ancienneté ou est plus ancien que son ou ses fichier(s) d'entrée.

Allez plus loin Ici.

Génération de la cible

On exécute MSBuild dans l'invite de commande de Visual Studio :

Dans le fichier myProject.csproj :

<Target Name="HelloWorld">
  <Message Text="Hello"></Message>
  <Message Text="World"></Message>
</Target>

En ligne de commande :

>msbuild myProject.csproj /t:HelloWorld

L'exécution avec le commutateur /t trouve la cible HelloWord et l'exéctute en sortie dans la fenêtre de commande on obtient :
Hello
World

Allez plus loin Ici.

MSBuild autres caractéristiques

Création de Tâches Inline Ici.

Quelques limitations de MSBuild

optimisé et facile d'utilisation qu'en association avec Visual Studio.

manuellement pénible et long d'écriture fichier dû au temps d'apprentissage de la syntaxe ...

les paramètres sont tous globaux.

plusieurs possibilités de référencer un item ou la valeur d'une propriété

la qualité de la documentation (semble s'être améliorée ...)

On parle de Ant ou NAnt également de GNU Make.

Nouveauté de la version MSBuild 4.5

Vous pouvez spécifier qu'une tâche s'exécute "out-of process" pour cibler un autre framework.net.

Vous pouvez générer des binaires qui ciblent un processeur ARM.

L'attribut d' ToolsVersion pour déterminer la version de l'ensemble d'outils MSBuild.

Nouveaux éléments du langage :

VisualStudioVersion

DoesTaskHostExist

Item

   KeepMetadata

   RemoveMetadata

   KeepDuplicates

ContinueOnError

   <Delete Files="@(Files)" ContinueOnError="WarnAndContinue"/>

   WarnAndContinue

   ErrorAndContinue

   ErrorAndStop