“Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information”

Voici le petit message d’amour que peut vous renvoyez votre ami la CLR lorsque vous essayez d’exécuter une application qui :

• référence une assembly mixte (mêlant code natif et code managé) qui a été compilée pour être basée sur une version différente de la CLR utilisée par votre point d’entrée.

La solution à ce problème est assez simple, il suffit de rajouter une section dans votre fichier de config :

L’attribut useLegacyV2RuntimeActivationPolicy

La clé du problème se situe donc dans l’utilisation de l’attribut useLegacyV2RuntimeActivationPolicy qui est à false par défaut. Cet attribut permet de changer la politique de chargement de CLR au sein de votre application. Il y a eu en effet un gros changement à ce sujet :

• Dans l’ère pré-CLR V4, en V2 quoi, il n’était possible de charger qu’une seule version de CLR au sein d’un process. La politique par défaut était de charger toutes vos assemblies en utilisant la version la plus récente de la CLR que vous aviez à disposition. Cette stratégie a comme avantage que votre ancien code bénéficie automatiquement des améliorations apportées par des versions plus récentes de CLR. Mais cela pouvait posait des problèmes de compatibilité dans certains rares cas.
• Avec la CLR V4, il est à présent de charger différentes versions de CLR au sein d’un même process et afin de ne plus être confronté aux problèmes de compatibilité la politique de chargement a changé. A présent les assemblies basées sur la CLR 4, utilisent la CLR 4, et les autres utilisent la version la plus récente inférieure à la V4.

Le problème avec les assemblies mixtes c’est que la CLR doit être capable de savoir quelle est la CLR a utiliser lorsque un thread natif appel du code managé. Il faut donc désactiver le side by side afin d’avoir une seule version identifiable.

Mais pourquoi ça marche très bien depuis mes tests unitaires ?

Confronté au problème une de mes premières questions a été de comprendre pourquoi mon code fonctionne très bien depuis mes tests unitaires alors qu’il plante lorsque je l’appelle depuis mon application. Le moteur d’exécution des tests unitaires MSTest est QTAgent.exe (QTAgent32.exe en version 32 bits, et oui VS 2010 supporte enfin l’exécution de tests unitaires en 32 et 64 bits). Si l’on va farfouiller un petit peu dans le dossier C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE à la recherche des fichiers de configs des tests runners on se rend compte que Microsoft a configuré le chargement de runtime via le fameux attribut useLegacyV2RuntimeActivationPolicy.

Ce qui veut donc dire que par défaut tous vos tests unitaires utiliseront uniquement la V4 de la CLR et que le hosting de CLR Side by Side est désactivé pour tous vos tests unitaires.

Si vous souhaitez commencer à vous former sur Visual Studio 2010 et le framework .net 4.0, sachez que Microsoft vient de publier une première version d'un training kit contenant des slides ainsi que des labs sur des sujets tels que : ParallelFX, VB10, C# 4, F#, ASP.net Ajax 4.0, etc...

Comme la précédente version dédiée à VS 2008, ce training kit est construit autour d'un site web vous permettant de sélectionner les ressources qui vous intéresse.

En savoir plus :
http://www.microsoft.com/downloads/details.aspx?FamilyID=752cb725-969b-4732-a383-ed5740f02e93&displaylang=en

Cette présentation fait partie des sessions de la PDC de cette année qu'il faut absolument visionner. Présenté par un des pères du C# (Anders Hejlsberg), l'ensemble des nouveautés qui seront proposés par la version 4 de C# qui sera proposé avec Visual Studio 2010 sont abordées.

Premier constat rassurant, les changements sont moins nombreux et moins importants que ceux introduits au passage de C# 2 à C# 3. L'essentiel de ces nouveautés concerne :

• l'ajout d'un mot clé dynamic  qui permet de manipuler des types à la manière des langages à typage dynamique c'est à dire que nous avons la possibilité d'indiquer au compilateur de ne pas s'occuper de savoir si une méthode Foo est présente sur le type manipulé avec le fameux mot-clé, mais d'uniquement tenter de l'appeler lors de l'exécution. L'intérêt de cette nouveauté est de permettre une meilleure interopérabilité avec les langages dynamiques présents dans le monde .net tels que Iron Ruby mais également de manipuler de manière plus simple les objets COM. Bien entendu le but n'est pas transformer le langage C# en langage dynamique mais de lui offrir la possibilité de profiter de certains avantages de cette gestion des types. L'interface IDynamicObject est également ajouté afin de définir directement en C# des objets à manipuler de manière "dynamique". A noter que le Visual Basic dispose depuis la version 4 d'une partie de cette fonctionnalité grâce à l'implémentation du latebinding qui permettait d'appeler les méthodes que l'on souhaitait sur un simple type Object.
• le support des paramètres optionnels et nommés également supportés par Visual Basic depuis bien longtemps. Je rassure de suite les puristes de la POO l'objectif n'est pas de remplacer les surcharges de méthodes mais de simplifier l'interop avec les composants COM et les API basés sur cette technologie comme... Microsoft Office. Fini le cauchemard des ref missing...
• Le support de la co-variance et de la contra-variance au niveau des méthodes. La co-variance étant déjà disponible au niveau des délégués depuis C# 2.

TL16 The Future of C# (Note:5/5)

Slides PPTX - Vidéos WMV-HQ

Quelques bloggueurs influents ont commencé à commenter la nouvelle relayée il y a quelques jours :

• Ayende http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx
• David Hayden http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx

Un des membres de l'équipe Linq To SQL a répondu à l'ensemble des craintes liées à la publication du post de l'équipe ADO.net. Ce dernier tente de calmer le jeu en indiquant que Linq To SQL ne va pas disparaitre du framework et qu'il continuera d'être maintenu au travers de corrections de bugs par exemple. (cf : http://damieng.com/blog/2008/10/31/linq-to-sql-next-steps)

Il n'en reste que Microsoft ne recommande l'utilisation que d'un seul et unique provider LINQ pour accéder à des bases de données relationnelles : LINQ TO ENTITIES. Linq To SQL n'a donc pas d'avenir hors de la maintenance des applications existantes basés sur ce provider dont la simplicité d'utilisation a séduit de nombreux développeurs.

C’est la team ADO.net qui l’indique, Linq To SQL peut être considéré comme mort puisque l’équipe annonce que ce provider sera uniquement maintenu en vie grâce aux différents feedbacks des développeurs, Linq To Entities étant le provider à utiliser en priorité selon Microsoft.

Tous les détails :
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx