Pour plus de détails sur la structure d'un fichier, vous pouvez vous rendre dans les annexes dans la section « Structure d'un fichier de build ».

Un fichier de build est un simple fichier XML pour lesquels plusieurs extensions sont possibles. Même si toutes les extensions peuvent être utilisées (seul le format du fichier et son contenu seront importants), seules les extensions suivantes seront comprises par Visual Studio et permettront de la coloration syntaxique et une auto-complétion (intellisense) partielle.

Notez que le fichier XML doit bien sûr être valide. Nous verrons plus en détail comment nous en assurer à la section « S'assurer de la validité du fichier de build ».

Dans un premier temps, contentons-nous de savoir qu'un fichier de build vide a la structure suivante :

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

</Project>

Comme nous disions dans l'introduction, un fichier de build nous permet de réaliser des tâches diverses, c'est à dire des actions. De quel type d'action parlons-nous ? Citons par exemple :

• Compiler un projet
• Ecrire un message d'avertissement
• Exécuter un script ou exécuter le backup d'une base de données
• Créer un répertoire ou copier un fichier
• Créer un nouveau site web dans un IIS
• Redémarrer un serveur distant
• Créer un fichier de déploiement (zip, msi, wix, ...)

Cette liste n'est qu'un court exemple du type de tâche que l'on peut réaliser au cours d'une intégration continue : on peut effectivement virtuellement exécuter n'importe quelle action. (4)

Pour avancer, contentons-nous de savoir qu'il existe certaines tâches dans le framework .NET, la plus simple étant la tâche Message permettant d'écrire du texte. Une tâche Message s'utilise de la manière suivante :

<Message Text="Ceci est le texte qui sera généré par la tâche" />

Un Target a deux fonctions spécifiques :

• Être un point d'entrée pour le fichier de projet
• Être un regroupement d'actions.

Un fichier de build va être typiquement comme un programme procédural, qui va appeler des méthodes. Chacune de ces méthodes répondant logiquement aux concepts de cohésion et de responsabilité.

Les targets sont en fait les méthodes d'un fichier de build, méthodes qui pourraient être exécutées via le « programme » (ie lors de l'exécution du fichier de build) ou indépendamment (on exécute une des méthodes du programme).

Un fichier de build peut donc comporter un ou plusieurs target, et comme un target est un point d'entrée du fichier de build, un fichier sans target ne sera pas exécutable.

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

</Project>

Si on assemble alors les éléments précédents, on a notre fichier de build minimal qui va afficher un simple message :

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
   
   <Target Name="NomDuTarget">
      <Message Text="Ceci est le texte qui sera genere par la tache" />
   </Target>

</Project>

Pour exécuter le fichier ci-dessus, nous supposons avoir fait les étapes suivantes :

• Le contenu a été sauvegardé dans un fichier appelé « Fichier de base.proj » dans le répertoire « D:\ Fichiers de build »
• Vous possédez une version du framework .NET 2.0 ou supérieur

MsBuild "Fichier de base.proj"

Cela produira alors le résultat suivant :

Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3053]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 6/01/2009 18:31:52.
Project "D:\Fichiers de build\Fichier de base.proj" on node 0 (default targets).
  Ceci est le texte qui sera genere par la tache
Done Building Project "D:\Fichiers de build\Fichier de base.proj" (default targets).

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.31

Le code précédent ne fonctionnera bien sûr que si vous avez ajouté le chemin complet de MsBuild dans la variable d'environnement Path. Dans le cas contraire, vous devrez indiquer le chemin complet pour l'exécution.