Vous ne le savez peut-être pas, mais par défaut, les tests unitaires de VisualStudio s'exécutent dans un contexte COM monothread (appelé STA pour single-threaded apartment). Si cela peut paraitre surprenant au premier abord, cela s'explique chez Microsoft par une question de performances.

En tout été de cause, il est donc impossible de faire appel à des fonctions telles que 'WaitHandle.WaitAll()'.

Heureusement, il existe une solution pour exécuter les tests dans un environnement MTA : c'est configurable dans votre fichier '.testrunconfig'.

Sous Visual Studio 2005, repérez et modifiez la section suivante :

<apartmentState type="System.Threading.ApartmentState">
  <value__ type="System.Int32">1</value__>
</apartmentState>

Par défaut, la valeur de cet élément est 0 (ce qui est l'équivalent de ApartmentState.STA - la valeur par défaut de l'énumération), mais comme vous pouvez le voir, je l'ai changée en 1 (ce qui est l'équivalent de ApartmentState.MTA).

Dans Visual Studio 2008, le format du fichier .testrunconfig a changé et ce paramètre n'est plus présent par défaut. Mais il suffit d'ajouter la ligne suivante pour obtenir le même résultat :

<ExecutionThread apartmentState="1" />

Source : http://blogs.msdn.com/ploeh/archive/2007/10/21/RunningMSTestInAnMTA.aspx

Ce matin, une phrase prononcée par l'un de mes collègues de bureau m'a fait réagir. Voici ses propos :

Une petite pensée du matin.

En science, "l'effet Mencken" peut se résumer ainsi :

"Pour chaque problème complexe, il existe une solution simple, directe ... et fausse !"

Essayons de ne pas nous laisser piéger...

Tout d'abord, une petite précision : H. L. Mencken était avant tout un écrivain humoriste et satirique, mais certainement pas un scientifique.
Ensuite, honnêtement, je n’ai aucune idée de la portée que peut avoir cet « effet » dans la communauté scientifique. Mais en revanche, en informatique, c’est un paradigme largement suivi, bien malheureusement.

Personnellement, je suis franchement en totale opposition avec cette idée qu’il est nécessaire qu’une solution soit complexe pour être bonne. Car c’est bien l’idée qu’il y a derrière cette phrase.

Sans basculer dans l’excès inverse, je pense que plus une solution est simple, plus elle est efficace. Evidemment, on ne peut pas répondre simplement à toute problématique (ce serait une vision trop simpliste). Mais chercher à y tendre, dans une mesure raisonnable, me semble beaucoup plus sain.

Or comme je le disais, c’est loin d’être le cas dans le monde de l’informatique avec, malheureusement, les développeurs et architectes en premiers lieux.

Cédric.

Je faisais quelques recherches sur la meilleure façon d’implémenter en .NET une architecture de plugins lorsque je suis tombé sur une nouvelle API apparue dans .NET 3.5 : System.AddIn

La principale source d’information dessus, c'est le blog de l’équipe en charge de son développement chez Microsoft :

http://blogs.msdn.com/clraddins/

Ainsi que 2 articles (en français) parus dans MSDN Magazine

http://msdn.microsoft.com/msdnmag/issues/07/03/CLRInsideOut/default.aspx?loc=fr

Je vous en recommande chaudement la lecture, notamment parce que cette architecture de plugin permet de résoudre la plupart des problèmes que l’on rencontre inévitablement lorsqu’on développe son propre système de plugin.

Mais on y trouve aussi certains concepts avancés très intéressant, comme la prise en charge de la mise à jour LIVE d’un AddOn (sans redémarrer l’application) et surtout le chargement des AddOn dans un processus séparé afin de garantir la stabilité de l’application principale.

Si charger un Assembly est relativement facile en C# (à l'aide de la fonction LoadFile(), membre de la classe System.Reflexion.Assembly), il est en revanche bien difficile de les décharger (lorsqu'on utilise plus le plugin par exemple).

La solution consiste alors à charger chaque plugin dans un AppDomain séparé. En effet, un AppDomain possède bien, lui, une fonction Unload(). Et lorsqu'on décharge un AppDomain, l'ensemble de ses Assembly le sont également.

Plus d'informations (en anglais) : Dynamically loading and Unloading Assemblies in C#

Dans le même style, mais plus récent et en français : HotPlug Manager

Ceci va paraitre comme une évidence au regard d'un grand nombre de personne, mais qui est généralement totalement oublié par la plupart des novices en base de données.

Quelle est la méthode la plus simple pour optimiser une base de données ? L'indexation bien entendu !

Combien de fois ai-je vu des base de données où le design avait été bien réfléchi, qu'il soit complexe ou non, mais pour laquelle aucun index (autre que ceux définis par défaut pour chaque table) n'avait été défini...

Ok, il est possible que dans certain cas (rare à mon avis), la présence d'un index ne change rien (mais c'est très probablement lié à un mauvais usage de la base de données). Mais sinon, dans tous les projets sur lesquels j'ai eu à intervenir (que ce soit comme auteur principal ou comme consultant), des gains substantiels ont pu être obtenu pas la création d'index bien choisis.

J'ai même un exemple récent (la semaine dernière) où les temps ont été divisé par 100 et sans aucune modification du code, rendant simplement exploitable une fonctionnalité qui était absolument inutilisable avant cela.

Je ne disserterai pas sur l'art de créer des index, le sujet est vaste, et suffisamment documenté par ailleurs. Mais j'insiste juste sur ce point : posez vous la question sur le ou les colonnes les plus sollicitées dans vos requêtes, et vérifier si la mise en place d'index ne pourrait pas aider à l'optimisation de vos requêtes...

Cela faisait quelques temps que j'hésitais, les blogs sont devenu omni-présent sur le net, (presque) tout le monde possède le sien, la plupart des requêtes Google y conduisent...

Alors, est-ce un simple effet de mode ? Je le pensais au début, avec en prime pour tout blogueur un besoin jouissif de s'afficher en public sur la toile. Ce n'est vraiment pas ce qui me donnait envie d'ouvrir le mien... en plus, pour y écrire quoi ? Et lu par qui ?

Mais maintenant, avec un peu plus de recule, j'ai compris autre chose : les blogs sont une formidable source d'information. Le principal intérêt (à mes yeux), c'est de pouvoir y noter "à la volée" les différents problèmes rencontrés, les solutions apportées, et ainsi se faire une véritable base de connaissance perso.

Oui, perso car dans un premier temps, c'est avant tout pour moi que j'écris ces lignes, pour ne pas oublier... Mais comme il est vrai que cela ne coute rien de partager ça (il n'y a rien de privé dans mes articles), alors autant rendre cet connaissance publique et peut-être en faire profiter quelques-uns (si jamais quelqu'un fini par tomber sur ce site).

Un autre avantage est de pouvoir plus facilement partager son expérience avec ses collègues de bureau (surtout lorsqu'on travaille à distance). Evidement, il sera plus sage d'éviter d'aborder tout sujet plus confidentiel, d'autres support de communication étant plus approprié dans ces cas là...

Bon, je m'arrête là pour ce premier post, ne sachant pas de toute façon comme cette tentative va évoluer.