Another .NET Blog

This article is an english translation of this one.

This article is designed for those who, like me, must deal with 2 versions of a same assembly, depending on you have to work on a 32 or 64 bits OS.

In my case, the faulted assembly is System.Data.SQLite.dll, which allows to use SQLite databases under the .Net framework. Therefore, this assembly exists in 2 flavors: 32 and 64 bits. The problems began to arise when I started to build some unit tests to check the behaviour of my repositories. At the beginning, I was developing on 32 bits PC, referencing the 32 bits assembly, and all was fine. But since then, I work as well on a 32 bits PC as on a 64 bits one, and I always have to delete the reference to the assembly, and replace it with a reference to the assembly with the same bitness as the architecture on which the tests are runned.

Not so great...

But that time is now revolved! And if you encounter the same problem, know that a solution does exist. And here it is...

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...

Dans cet article, je ne vais pas vous expliquer ce que sont Caliburn et PostSharp, leurs documentations et exemples respectifs le font déjà très bien, mais je vais expliquer comment créer un aspect que Postsharp va appliquer à des classes que nous définirons, et qui aura pour résultat d'implémenter l'interface INotifyPropertyChanged dans ces classes, et d'appeler automatiquement l'évènement PropertyChanged lorsque la valeur des propriétés publiques de ces classes va être modifiée.

Si vous connaissez déjà Postsharp, ou avez été regardé sur leur site, vous aurez sûrement remarqué qu'il existe déjà un aspect qui permet d'implémenter l'interface INotifyPropertyChanged, et d'appeler PropertyChanged à chaque changement de valeur de la propriété.

De même, si vous connaissez Caliburn, vous aurez également remarqué que les classes dont vous devez dériver pour implémenter vos ViewModels dérivent elles-même d'une classe abstraite nommée PropertyChangedBase, qui implémente INotifyPropertyChanged, et qui propose une fonction nommée NotifyOfPropertyChange, à laquelle vous passez comme paramètre le nom de la propriété qui a été modifiée.

L'aspect que je vais vous montrer va nous permettre de mixer ces 2 approches.

Pour clore le chapitre sur l'utilisation de Rx pour mon application de gestion de mises à jour, je vais terminer comme annoncé par vous montrer comment je lance les exécutables téléchargés de manière asynchrone, afin de ne pas bloquer le thread de la vue pendant l'installation.

On continue avec la petite série d'articles Rx avec cette fois une nouvelle résolution de "problème". On a vu lors de l'article précédent comment ignorer les erreurs lorsque des adresses de téléchargement étaient invalides ou injoignables. Nous allons voir cette fois-ci comment lancer tous les téléchargements simultanément et comment attendre qu'ils soient tous terminés avant de les exécuter les uns après les autres pour les installer.

J'ai déjà parlé à plusieurs reprises des reactives extensions, que l'on appelle plus familièrement Rx. Je me suis dit que ce serait une bonne idée que de vous les présenter plus en détail. Je ne vais pas écrire un article qui va tout vous expliquer depuis le début, car il existe déjà beaucoup de ressources. (ici, ici, ou bien ici, ou même encore là) Je me suis donc dit que ça serait peut-être une meilleure idée que de vous expliquer comment ça peut fonctionner grâce à un exemple concret. Et comme j'avais déjà un article expliquant comment réaliser une opération asynchrone en utilisant la TPL, j'ai repris cet exemple, en utilisant cette fois Rx.

Je vais aujourd'hui vous présenter le résultat d'un refactoring de masse dans une série de tests unitaires, qui a permis d'accroitre très fortement la lecture des tests, et surtout leur compréhension.

La classe testée a pour but de gérer les mises à jour d'une liste de programmes installés sur un ordinateur. Cette classe est très "high-level" dans la mesure où elle permet d'aller récupérer la liste de toutes les mises à jour de toute une gamme de produits, de savoir pour chaque programme quelles sont les mises à jour à installer, puis bien évidemment de télécharger ces mises à jour et les installer.

Comme vous le voyez, cette classe consiste en beaucoup de sous-tâches, qui vont toutes communiquer avec le monde extérieur (internet notamment, pour l'obtention des mises à jours et leur téléchargement). Dans le but d'obtenir des tests unitaires les plus isolés possibles, j'en suis bien sûr arrivé à décomposer chacune de ces sous-tâches et à les identifier par des interfaces bien distinctes, pour lesquelles je laisse à Ninject le soin de les injecter comme il faut.

Rien que du très classique en somme. Le hic étant que cette classe nécessite du coup l'injection de beaucoup de dépendances (5 !) et que la mise en place des mocks dans chaque test rend le test trop long, et sa relecture difficile.

Voici donc une solution pour éviter ce genre de soucis. Solution qui se base, comme vous allez le constater, sur une hiérarchie de Providers Ninject, et une classe de construction d'un Module, qu'on rendra "Fluent".

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!

La copie d'objets en C# est vraiment un vaste débat, dans lequel il est facile de se perdre au vu des différentes solutions proposées lorsque vous faites une petite recherche sur Google.

Je vais essayer dans cet article d'expliquer pourquoi il ne vaut mieux pas utiliser l'interface ICloneable du framework, les 2 types de copie réalisables en C#, et je finirai par un exemple concret qui mettra en évidence (qui le tentera du moins) quelle méthodologie appliquer en fonction de ce que vos classes ont à copier.