Scénario: Une application ciblant .Net 3.5 est parfaitement capable d'ajouter des compléments COM ciblant .Net framework 1.1, 2.0 ou 3.5.Clarification sur la version .Net (2.0, 3.5, 1.1) Comportement du COM complémentaire avec .Net 4.0 Processus
Dès que la même application est migrée vers l'infrastructure cible 4.0. Certains de ces compléments ont commencé à donner des problèmes principalement avec les appels de com, les mêmes appels fonctionnent correctement lorsque l'application cible le framework 3.5. Utilisation de l'attribut config ... "useLegacyV2RuntimeActivationPolicy =" true "", qui Activer la politique d'activation runtime .NET Framework 2.0 pour l'exécution choisie, qui consiste à lier les techniques d'activation d'exécution héritées (telles que la fonction CorBindToRuntimeEx) à l'exécution choisi à partir du fichier de configuration au lieu de les écraser à CLR version 2.0. Certains de ces problèmes de début d'add-in ont commencé à fonctionner correctement avec la cible .Net 4.0.
Encore certains d'entre eux échouent à cause de cet attribut, et une fois enlevés ceux qui ont travaillé à cause de cela commencent à échouer.
Une suggestion pour que tous ces compléments fonctionnent avec le framework cible 4.0?
Cela n'a aucun sens d'utiliser COM dans ce scénario, une application hôte qui cible 4.0 doit utiliser une liaison d'assembly .NET normale. Je suppose que vous pourriez contourner cela en utilisant la liaison tardive, mais alors la fonctionnalité 4.0 qui permet le chargement de plusieurs versions de CLR ne peut pas fonctionner. "Certains d'entre eux échouent" est un diagnostic désespérément large et non spécifique que vous ne pouvez pas obtenir ici. –
Eh bien cela ne peut pas être changé car il est limité par une spécification qui cible .Net 3.5, et qui devient une limitation maintenant si toutes les applications doivent se déplacer vers des versions .Net plus récentes. .Net a vraiment fourni un goulot d'étranglement ici. – Abby