Category Archives: ALM

Nant Episode 1 – Présentation

NAnt est un langage de script adapté à la compilation de projets. les scripts NAnt sont simplement des fichiers XML. NAnt possède 3 concepts de base:

  • les “targets” (cible): les targets rassemblent des ensembles de tâches. On peut dire très naïvement que ce sont les “méthodes” du script. La “target” lancée au démarrage est soit la target par défaut, soit celle définie lors du lancement (il peut aussi y en avoir plusieurs à lancer)
  • les taches
  • les propriétés: elles peuvent être définies en dehors du script lors du lancement

Tous ces éléments se retrouvent sous un noeud principal, le projet.

Si l’on s’arrète à cela, NAnt ressemble trait pour trait à MSBuild. Nous allons voir que non. Nant se détache de MSBuild sur plusieurs points. En particulier:

  • On peut imbriquer les tâches dans des tâches, pour par exemple reproduire un graphe d’appel et pas seulement une séquence.
  • la gestion des erreurs est plus simple
  • la syntaxe des expression est très puissante et très extensible

On peut lancer un script via la ligne de commande de NAnt, ou embarquer nant dans une application (nous verrons plus tard comment et pourquoi).

NAnt est écrit en .Net, et vient de Ant son frère de Java. Toutes les tâches NAnt sont écrites en .Net est NAnt doc est très extensible.

Commençons par un script simple:

 
<?xml version="1.0" encoding="utf-8"?>
<project name="hello" default="main_target">
  <target name="main_target">
    <echo message="Hello from nant" />   
  </target>
  <target name="other_target">
    <echo message="Hello from nant (other)" />
  </target>
</project>

La ligne de commande est la suivante: nant -buildfile:HelloFromNAnt_1.build

image

Changeons un peu la ligne de commande: nant -buildfile:HelloFromNAnt_1.build other_target

image

La cible a changé, par défaut le script pointe sur “main_target”, mais il est possible de choisir.

On peut aussi appeller une cible d’une autre cible:

 
<?xml version="1.0" encoding="utf-8"?>
<project name="hello" default="main_target">
  <target name="main_target">
    <echo message="Hello from nant" />
    <call target="other_target" />
  </target>
  <target name="other_target">
    <echo message="Hello from nant (other)" />
  </target>
</project>

Lançons ce script:

image

Le prochain script montre une partie de la puissance de NAnt: les propriétés

 
<?xml version="1.0" encoding="utf-8"?>
<project name="hello" default="main_target">
  <target name="main_target">
    <echo message="Hello from nant" />
    <call target="Target_${cible}" />
  </target>
  <target name="Target_A">
    <echo message="Hello from A" />
  </target>
  <target name="Target_B">
    <echo message="Hello from B" />
  </target>
</project>

image

j’ai créé une propriété via la ligne de commande “cible”. et j’ai appellé la target “Target_${cible}” la syntaxe ${} permet d’executer une expresssion et pas seulement lire une variable. la chaîne résultante est devenue Target_B d’où le résultat.

Dans le prochain billet nous verrons les tâches les plus interessantes de NAnt.

[EN] Links of the week (Nov 11th, 2011)

Some stuff I’ve seen this week and I’d like to share:

.Net/Langages

ALM:

Web

@+

[EN] Links of the week (Nov 6th, 2011)

Some stuff I’ve seen this week and I’d like to share:

.Net/Langages

ALM:

@+

[FR] Les Journées SQL Server à Paris les 12 & 13 décembre 2011

A ne pas manquer dans moins de 2 mois le GUSS avec l’aide de toute la communauté organise un évènement de 2 jours autour de la plaforme SQL Server. J’y serai pour présenter comment l’on peut industrialiser le developpement sur SQL Server avec VS 2010 ainsi que ce que l’on pourra faire bientôt avec “Juneau”.

Les journées SQL Server se dérouleront au centre de conférence de Microsoft.

@+

[FR] Quels outils sur une machine de build?

On ne devrait jamais avoir à se connecter à une machine de build. Mais cela n’est vrai que lorsque le processus de build tourne rond. Mais des fois, tout déraille et il se peut que cela ne compile pas sur la machine de build, mais que cela compile sur les postes des utilisateurs (le fameux “ça marche sur ma machine”). Il y a plusieurs causes à cela:

Cause n°1. Certains développeurs “oublient” d’archiver des fichiers. Cela arrive bien trop souvent! Dans ce cas on est bien content d’avoir Visual Studio sur la machine de build pour pouvoir ouvrir le projet. Je conseille donc vivement d’avoir Visual Studio  sur chaque machine de build. Surtout que cette installation est souvent nécessaire pour certaines opérations. Des fois c’est plus tordu que cela: des références projets peuvent être remplacées par des références binaires vers des composants de la solution et cela change l’ordre de compilation. Cela ne se voit pas dans VS et comportement bizarre assuré! Il arrive aussi de devoir comparer le code à compiler à sa version précédente, dans ce cas, un outil comme KDiff est bien utile.

Cause n°2. Les dépendances des projets ont changé: un nouveau projet a besoin de compiler, ou un composant externe a besoin d’être installé. Dans ce cas, les logs de la build sont une bonne source d’indices. Mais des fois, il faut aller sur la machine, ouvrir le projet – comme pour la première étape – et ajouter le composant nécessaire. Je vous conseille de toujours maintenir une liste avec les composants à installer. Sur cette liste on retrouve généralement:

  • des composants graphiques ou non d’éditeurs tiers
  • des SDK Microsofts (comme par exemple celui de Blend: on l’oublie souvent celui là)
  • des utilitaires, générateurs de code ou autres.

Cause n°3. Rien à changé, mais le code ne compile plus. Il faut alors mettre les mains dans le moteur: voir si il y a un blocage dans le processus de build, analyser les scripts. Pour toutes ces raisons, rien de tel que Notepad++ et des Sysinternals tools pour cela. S’il faut debugger des programmes qui font parti du processus de build, il faut alors sortir les grands moyens. Quelques fois le remote debugger de Visual Studio suffit, mais lorsqu’il faut attacher un debugger au départ d’un projet, les Debuggings Tools sont nécessaires (Plus de détail ici).

Tous ces programmes n’ont pas besoin d’être installés, il suffit de copier les binaires. Pour être sûr d’avoir une machine de build à jour, il suffit de synchroniser un dossier contenant ces outils via le contrôleur de source de TFS. Un simple “get latest version” permet ensuite de mettre à jour la machine.

@+

[FR] 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.

@+