Que fait «useLegacyV2RuntimeActivationPolicy» dans la configuration .NET 4?

214

Lors de la conversion d'un projet qui utilisait SlimDX, et qui a donc du code non managé, 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 pas être chargé dans le runtime 4.0 sans informations de configuration supplémentaires.

La recherche sur Google m'a donné la solution, qui consiste à ajouter ceci à la configuration des applications:

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

Ma question est, que useLegacyV2RuntimeActivationPolicyfait-on? Je ne trouve aucune documentation à ce sujet.

.net .net-4.0 app-config mixed-mode Cameron MacFarland
la source

Réponses:

165

Après un peu de temps (et plus de recherche), j'ai trouvé cette entrée de blog de Jomo Fisher.

L'un des problèmes récents que nous avons vus est qu'en raison de la prise en charge des runtimes côte à côte, .NET 4.0 a changé la façon dont il se lie aux anciens assemblages en mode mixte. Ces assemblys sont, par exemple, ceux qui sont compilés à partir de C ++ \ CLI. Les assemblys 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 pas être chargé dans le runtime 4.0 sans informations de configuration supplémentaires.

[Couper]

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

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

Cela ressemble donc à la façon dont le runtime charge les assemblages en mode mixte a changé. Je ne trouve aucun détail sur ce changement, ni pourquoi il a été fait. Mais l' useLegacyV2RuntimeActivationPolicyattribut revient au chargement CLR 2.0.

Cameron MacFarland
la source
28
Il convient de noter ici que la réponse de Marklios ( stackoverflow.com/questions/1604663/… ) fournit un lien vers son explication approfondie concernant ce changement.
Steffen Opel
1
Une explication approfondie de cela peut être trouvée sur MSDN (bien qu'elle ne mentionne pas explicitement la solution mentionnée ci-dessus): msdn.microsoft.com/en-us/magazine/ee819091.aspx
Mouhammed Soueidane
Que faire si j'ai ajouté ceci à la fois à la configuration de mon application et à une configuration de mon projet UnitTest et que je reçois toujours une erreur de chargement de fichier lors de l'exécution des tests. Dois-je poster une nouvelle question?
CodenameCain
126

Voici une explication que j'ai écrite récemment pour aider au vide des 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 bits les plus pertinents:

[Installer .NET] v4 est «sans impact». Il ne devrait pas modifier le comportement des composants existants une fois installés.

L'attribut useLegacyV2RuntimeActivationPolicy vous permet essentiellement de dire: «J'ai certaines dépendances sur les API de shim héritées. Veuillez les faire fonctionner comme ils le faisaient en ce qui concerne le temps d'exécution choisi. »

Pourquoi n'en faisons-nous pas le comportement par défaut? Vous pourriez faire valoir que ce comportement est plus compatible et rend le portage du code des versions précédentes beaucoup plus facile. Si vous vous en souvenez, cela ne peut pas être le comportement par défaut car cela rendrait l'installation de la v4 percutante, ce qui peut casser les applications existantes installées sur votre machine.

Le post complet explique cela plus en détail. Chez RTM, les documents MSDN à ce sujet devraient être meilleurs.

Mark Miller
la source
user20493, pouvez-vous exécuter votre application avec la variable d'environnement COMPlus_CLRLoadLogDir définie sur un répertoire vide auquel l'application a un accès en écriture et partager les journaux résultants (veuillez scrub pour tout PII avant le partage). Cela peut aider à expliquer ce qui se passe. L'attribut config peut ne pas être appliqué au contexte dans lequel votre application s'exécute.
Mark Miller
Ce lien devrait également vous aider à comprendre quel est le problème et ce que la solution fait pour vous: msdn.microsoft.com/en-us/magazine/ee819091.aspx
Mouhammed Soueidane