Que fait "useLegacyV2RuntimeActivationPolicy" dans la configuration de .NET 4 ?

Question

Lors de la conversion d'un projet utilisant SlimDX, et dont le code n'est donc pas géré, en .NET 4.0, j'ai rencontré l'erreur suivante :

L'assemblage en mode mixte est construit par rapport à la version 'v2.0.50727' du runtime et ne peut être chargé dans le runtime 4.0 sans informations de configuration supplémentaires.

En cherchant sur Google, j'ai trouvé la solution, qui consiste à ajouter ceci à la configuration des applications :

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

Ma question est la suivante : quel est le useLegacyV2RuntimeActivationPolicy à faire ? Je ne trouve aucune documentation à ce sujet.

Answer 1

Après un peu de temps (et plus de recherches), j'ai trouvé cet article de blog par Jomo Fisher.

L'un des problèmes récents que nous avons constatés est que, en raison de la prise en charge des moteurs d'exécution côte à côte, .NET 4.0 a modifié la manière dont il se lie aux anciens assemblages en mode mixte. Ces assemblages sont, par exemple, ceux qui ont été compilés à partir de C++. \CLI. Les assemblages DirectX actuellement disponibles sont en mode mixte. Si vous voyez un message comme celui-ci, vous savez que vous avez rencontré le problème :

L'assemblage en mode mixte est construit par rapport à la version 'v1.1.4322' du runtime et ne peut être chargé dans le runtime 4.0 sans informations de configuration supplémentaires.

[Snip]

La bonne nouvelle pour les applications est que vous avez la possibilité de revenir à la liaison d'ère .NET 2.0 pour ces assemblages en définissant un indicateur app.config comme suit :

<startup useLegacyV2RuntimeActivationPolicy="true">
  <supportedRuntime version="v4.0"/>
</startup>

Il semble donc que la façon dont le runtime charge les assemblages en mode mixte a changé. Je ne peux pas trouver de détails sur ce changement, ou pourquoi il a été fait. Mais le useLegacyV2RuntimeActivationPolicy permet de revenir au chargement du CLR 2.0.

Answer 2

Voici une explication que j'ai écrite récemment pour combler le manque d'informations sur cet attribut. http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx (lien Internet Archive Wayback Machine)

Pour citer les passages les plus pertinents :

La v4 de [Installer .NET] est "sans impact". Elle ne devrait pas modifier le comportement des composants existants lorsqu'elle est installée.

L'attribut useLegacyV2RuntimeActivationPolicy vous permet essentiellement de dire : "J'ai quelques dépendances sur les API de shim anciennes. Veuillez les faire fonctionner de la manière dont elles fonctionnaient auparavant en ce qui concerne le runtime choisi."

Pourquoi ne pas en faire le comportement par défaut ? Vous pourriez argumenter que ce comportement est plus compatible et qu'il facilite le portage du code des versions précédentes. Si vous vous rappelez, cela ne peut pas être le comportement par défaut car cela rendrait l'installation de la v4 impactante, ce qui peut casser les applications existantes installées sur votre machine.

L'article complet explique cela plus en détail. A la RTM, les docs MSDN sur ce sujet devraient être meilleurs.

Answer 3

Je cherchais exactement la même chose, j'ai trouvé de la documentation "preview", sur les changements qui ont été apportés à la politique d'activation. Voici le lien : http://msdn.microsoft.com/en-us/library/dd233115%28VS.100%29.aspx

Answer 4

Comme d'autres réponses le suggèrent, vous pouvez essayer d'utiliser useLegacyV2RuntimeActivationPolicy . Mais, d'abord apprendre les dommages de ce drapeau à votre application, de ce poste et les liens qui en découlent.

Answer 5

Doc pour élément de démarrage sur MSDN