IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Intégration Continue avec Visual Studio et Team Foundation Server - Partie II, Présentation de MsBuild et de TfsBuild

Intégration Continue avec Visual Studio et Team Foundation Server - Partie II, Présentation de MsBuild et de TfsBuild


précédentsommairesuivant

1. Contexte

Nous avions vu - dans la première partie de cet article - une présentation de l'intégration continue, ainsi que des outils utiles dans le monde Mirosoft.NET : MsTest et Static Code Analysis.

MsTest nous permettait des tests unitaires pour nos projets, tandis que Static Code Analysis nous permettait de valider notre code source contre une série de règles pré-établies.

Nous allons voir maintenant deux autres outils : MsBuild - disponible depuis Visual Studio 2005 (et ce quelque soit la version) - et TfsBuild.

De nombreux liens vers la MSDN seront également donnés de façon à permettre au lecteur d'approfondir davantage les sujets traités.
Notez que ces liens seront toujours donnés vers la MSDN online.
Tous ces liens seront regroupés dans l'appendix (voir la bibliographie) et seront aussi donnés vers une installation locale de la MSDN (en supposant une utilisation de la MSDN fournie avec Visual Studio 2008 SP1).

2. Présentation brève de MsBuild

MsBuild est la pierre angulaire de l'intégration continue dans le monde Microsoft : c'est l'outil qui permet l'automatisation de tâches diverses (compilation, déploiement d'une solution, exécution de tests, ...).

La communauté Microsoft avait déjà fourni des outils d'intégration continue - pour la plupart des portages du monde Java - comme CruiseControl.NET et NAnt. Mais c'est à partir de la version 2005 que Microsoft inclut son propre moteur au sein de Visual Studio.

Il est même utilisé en interne pour la compilation des solutions et des projets. Il est donc beaucoup plus « simple » (ou tout du moins envisageable sans refaire tout le processus en ligne de commande) de paramétrer la compilation de nos projets dans Visual Studio en modifiant le fichier de build utilisé par Visual Studio. (1)

MsBuild permet en fait d'exécuter un fichier de projet (ou fichier de build), traditionnellement d'extension « .proj » ou « .target ». (2) Il s'agit en fait d'un fichier XML représentant une série d'actions.

Ce fichier de projet génèrera une fois exécuté un fichier texte comportant tous les messages, avertissements ou erreurs relatifs à l'exécution.

L'outil MsBuild est installé avec le framework, autrement dit dans le répertoire « %Windir%\Microsoft.NET\Framework\VersionFramework », soit typiquement dans les répertoires :

  • « %Windir%\Microsoft.NET\Framework\v2.0.50727 » pour .NET 2.0
  • « %Windir%\Microsoft.NET\Framework\v3.5 » pour .NET 3.5

précédentsommairesuivant
Notez cependant que le fichier utilisé par Visual Studio est très complexe et dépasse largement le périmètre de ce document. Il est totalement déconseillé de le modifier sans avoir une parfaite connaissance de la syntaxe des commandes utilisées. Il sera cependant beaucoup plus simple pour un projet en particulier de travailler sur le fichier « .csproj » qui est lui-même un fichier de build.
Ces fichiers de compilation (d'extension « .targets ») sont présents dans le répertoire « %Windir%\Microsoft.NET\Framework\VersionFramework ».
Notez que seules ces deux extensions seront reconnues par Visual Studio pour ajouter de la coloration syntaxique et de l'IntelliSense. Notez cependant que l'IntelliSense fournie dans ces types de fichiers est souvent approximative.

Copyright © 2009 Pierre-Emmanuel Dautreppe . Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC.