Another .NET Blog

Cet article est destiné à ceux qui, comme moi, doivent jongler entre 2 versions d'une même assembly, selon que vous travailliez sur un poste en 32 bits ou en 64 bits. Dans mon cas, le fichier incriminé est System.Data.SQLite.dll, qui permet d'utiliser des bases de données sous SQLite, depuis le framework .NET. Cette assembly existe donc, vous l'aurez compris, en 2 exemplaires: 32 et 64 bits.

Les soucis ont commencé à arriver pour moi lorsque j'ai commencé à mettre en place mes tests unitaires pour tester le comportement de mes repositories. Car au début du développement, j'étais sur un PC 32bits, avec la DLL 32bits référencée, et tout allait bien. Mais, je me suis mis à travailler aussi bien sur une machine 32 bits que sur une machine en 64 bits, et à chaque fois je devais supprimer la référence vers l'assembly, et la remplacer par une référence vers l'assembly spécifique à la plateforme sur laquelle les tests étaient lancés.

Bien lourd donc...

Mais depuis, c'est fini! Et si vous avez également le même souci, sachez qu'il existe une solution. Que voici sans plus attendre...

Si vous utilisez FxCop, vous avez déjà peut-être été énervé de devoir supprimer manuellement tous les messages de type IdentifiersShouldBeSpelledCorrectly, vous disant que vous avez mal orthographié un mot.

Par exemple, dans mon projet actuel, tous mes namespaces commencent par Emidee, que l'ami FxCop ne reconnait bien évidemment pas.

Pour éviter ce travail fastidieux et pas franchement intellectuel, il est possible d'ajouter le(s) mot(s) en question dans le fichier CustomDictionary.xml situé dans le répertoire d'installation de FxCop. Le souci étant que si vous importez vos sources sur un autre PC, vous ne bénéficierez plus de cet avantage.

La solution à ce problème est toute simple: FxCop va recherche ce fichier CustomDictionary.xml dans 3 emplacements différents:

1. dans le dossier d'installation de FxCop
2. dans le dossier de l'utilisateur dont la session est ouverte (où exactement, j'avoue ne pas avoir cherché)
3. dans le dossier où se trouve le fichier de projet .fxcop

Comme généralement vous placez le fichier de projet fxcop dans vos sources (comme ici par exemple), il vous suffit de créer un nouveau fichier CustomDictionary.xml au même endroit, et le tour est joué!

Et pour en terminer, voici la structure à respecter:

<?xml version="1.0" encoding="utf-8"?>
<Dictionary>
  <Words>
    <Unrecognized />
    <Recognized>
      <Word>Emidee</Word>
    </Recognized>
    <Deprecated />
  </Words>
  <Acronyms>
    <CasingExceptions />
  </Acronyms>
</Dictionary>

A bientôt!

Nous voici enfin arrivés à la dernière partie de cette série d'articles relatifs à la configuration d'un serveur d'intégration continue avec Hudson. Dans cette très courte partie, je vais vous présenter 2 plugins à installer dans Hudson, qui permettront d'avoir sur la page d'accueil de votre projet un résumé des tâches à faire et bugs à résoudre, et également la liste de tous les warnings émis par le compilateur lors de... euh... la compilation :)

Poursuivons cette série d'articles en nous attardant désormais sur l'analyse du code des assemblies grâce à un outil que vous devez tous connaître (et si ce n'est pas le cas, je vous enjoins expressément à vous y intéresser): FxCop. D'une manière similaire à ce que nous avons fait auparavant avec les tests unitaires, nous allons là aussi "programmer" l'exécution de l'analyse dans le fichier NAnt, puis nous allons configurer Hudson pour afficher les résultats de cette analyse directement sur la page du projet.

On trouve sur internet un paquet de tutoriaux sur la configuration de divers serveurs d'intégration continue, basés sur des solutions différentes (TeamCity, Hudson, Cruise Control.NET...), avec des options différentes (FxCop, avec ou sans tests unitaires...). Le problème est que ces tutoriaux ciblent tout le temps .NET 3.5 ou 2.0 (normal me direz vous) et que les "options" proposées ne me conviennent pas, notamment concernant les tests unitaires (Personne n'utilise donc xUnit?)

Je me suis donc efforcé de faire fonctionner un serveur d'intégration continue qui remplirait les objectifs suivants:

1. Framework ciblé : .NET 4.0
2. Librairie de tests unitaires : xUnit
3. Utilisation d'outils d'analyse de code : FxCop
4. Couverture de code : nCover

Et je me propose donc de vous en relater les étapes lors de cette série d'articles.