Ca y est enfin, NAnt sort une nouvelle version le 22 octobre, il a fallu plus d’un an. Celle-ci cible maintenant le framework 4. NantContrib a aussi été mis à niveau.
Pour télécharger Nant, c’est ici: http://nant.sourceforge.net
Et NantContrib: http://nantcontrib.sourceforge.net
@+
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.
@+
Ce n’est pas vraiment une astuce, mais plutôt un conseil. Afficher dans l’explorateur de source les fichiers supprimés vous permettra la plupart du temps de retrouver ces fichiers et donc de pouvoir consulter leurs historiques.
L’option se cache dans les options de Visual Studio:
Et les fichiers se présentent sous cette forme:
@+
Ce fut le premier livre dans lequel j’ai pu découvrir la richesse de .Net, et il me sert encore (et oui tous le monde n’est pas en Framework 4 
). Le livre est à la fois en téléchargement libre en Français et en Anglais ici. Par exemple, pour tout comprendre sur les itérateurs et “yield return/break”, rendez vous en page 556. Encore bravo Patrick pour ton livre.
@+
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:
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.
@+