Si j'ai un assembly 2.0 CLR (code géré pur, pas de problèmes de mode mixte) que j'ai besoin de lier à partir d'une application CLR 4.0, le code 2.0 s'exécute sur le 2.0 CLR ou 4.0.Lors de la liaison d'un assembly géré .NET 2.0 à partir d'une application .NET 4.0, quel framework est utilisé?
Fondamentalement, y a-t-il un risque de rupture de 4.0 affectant le code 2.0?
La réponse ci-dessus est incorrecte. Vous obtenez côte à côte avec les cadres complets. Une application .Net 2 (notez que signifie EXE, pas la bibliothèque) ne fera pas la promotion automatique à .Net 4.
Mais si une application .Net 4 charge un assembly .Net 2, elle est chargée dans le même runtime (sinon comment pourraient-ils partager l'information). L'assembly .Net 2 est chargé dans le runtime .net 4 en utilisant un mode de compatibilité supposé minimiser les ruptures de modifications (principalement pour les changements de sécurité dans .Net 4).
Un assembly .Net 2 ne peut pas référencer un assembly .Net 4 car il ne possède pas de fonctions.
La seule exception à ce que je sais est si vous chargez un assembly .Net à partir d'une application C++. L'application C++ peut charger et héberger deux runtimes. Un assembly .Net 2 et un assembly .Net 4 peuvent être chargés, mais ils ne peuvent pas se parler directement. C'est ainsi que les procédures CLR fonctionnent dans SQL Server. Vous pouvez avoir un .NET 2 CLR Proc et un .NET 4 CLR Proc qui ne communiquent pas, mais qui sont tous deux chargés sur le serveur.
Il y avait un excellent article sur MSDN Magazine sur l'hébergement du framework .Net récemment, mais je ne le trouve pas maintenant. Peut-être que quelqu'un d'autre peut poster le lien.
Vous devriez donc pouvoir charger n'importe quel assemblage .Net 2 dans un exécutable .Net 4 sans trop de problèmes. Les seuls problèmes que j'ai vus sont avec les permissions de sécurité.
Fondamentalement, y a-t-il un risque de rupture de 4.0 affectant le code 2.0?
Nope. À partir de .NET 4, vous n'avez pas à vous soucier des problèmes de compatibilité du tout! La version 4 a introduit une nouvelle fonctionnalité appelée "In-Process Side-by-Side Execution", qui permet essentiellement de charger plusieurs versions du CLR dans le même processus. En d'autres termes, comme votre application principale s'exécute sur le runtime 4.0, vous pouvez lui indiquer de charger le runtime 2.0 lorsque vous chargez l'assembly 2.0 CLR. L'assembly 2.0 CLR utilisera le runtime 2.0, tandis que votre application continuera à utiliser le runtime 4.0.
Comment le spécifiez-vous? Je crois que vous pouvez simplement ajouter un fichier de configuration pour votre assembly 2.0 CLR (par exemple "My.dll.config" dans le même répertoire que "My.dll"), mais je ne l'ai pas essayé avec des DLL moi-même. Néanmoins, voici ce que vous mettez dans votre fichier de configuration de l'assemblage:
<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
</startup>
</configuration>
Ceci est correct, selon les docs. Cependant, il semble que parfois le compilateur C# va ajouter et alias les assemblys v2.0 qui provoquent alors des problèmes de chargement. Pouvez-vous expliquer cela? Voici un exemple: http: // stackoverflow.com/questions/3841911/link-to-a-net-v2-0-assembly-from-a-net-v4-0-assembly-apparait-to-link-a – codekaizen
Merci pour la réponse, mais j'ai donné cela va en créant un projet de test rapide. J'ai une application de console fonctionnant 4.0, et une bibliothèque de classe fonctionnant 3.5. J'ai créé un fichier de configuration comme spécifié, et Environment.Version est 4.0 pour les deux. – AlexWilson
Le fichier de configuration ne fonctionnera pas pour une DLL. Il doit être ajouté au fichier de configuration .EXE, puisque c'est ce qui est chargé par le moteur d'exécution. – codekaizen
si la réponse de htw n'a pas répondu pour vous, ou il se bloque sur vous. Jetez un oeil à cette
Homme, je l'ai fait avant et totalement oublié ce app.config
Je ne sais pas si vous parlez de l'article "CLR Hosting APIs": msdn.microsoft.com/en-us/magazine/cc163567.aspx – user276648