%windir%\Microsoft.NET\assembly\ est le nouveau GAC . Cela signifie-t-il que nous devons gérer deux GAC, l'un pour les applications .NET 2.0-3.5 et l'autre pour les applications .NET 4.0?
La question est, pourquoi?
Réponses
Trop de publicités?
Oui, puisqu'il y a 2 distincts Global Assembly Cache (GAC), vous aurez à gérer chacun d'eux individuellement.
Dans .NET Framework 4.0, le GAC est allé par le biais de quelques changements. Le GAC a été divisé en deux, un pour chaque CLR.
La version CLR utilisé pour les deux .NET Framework 2.0 et .NET Framework 3.5 est CLR 2.0. Il n'était pas nécessaire dans les deux précédents cadre de communiqués de diviser GAC. Le problème de la rupture des anciennes applications en Net Framework 4.0.
Pour éviter les problèmes entre CLR CLR 2.0 et 4.0 , le GAC est maintenant divisé en privé GAC pour chaque exécution.Le principal changement est que CLR v2.0 les applications ne peuvent pas voir le CLR v4.0 assemblées dans le GAC.
Pourquoi?
Il semble que ce soit parce qu'il y avait un CLR changement .NET 4.0, mais pas dans la version 2.0 à 3.5. La même chose s'est produite avec 1.1 à 2.0 CLR. Il semble que le GAC a la capacité de stocker les différentes versions des assemblées tant qu'ils sont de la même CLR. Ils ne veulent pas se casser les anciennes applications.
Voir les informations suivantes dans MSDN sur le GAC changements dans la version 4.0.
Par exemple, si les deux .NET 1.1 et .NET 2.0 partagé le même GAC, puis un .NET 1.1 application, le chargement d'un assemblage à partir de ce partage du GAC, pourrait obtenir .NET 2.0 assemblées, brisant ainsi l' .NET 1.1 application
La version CLR utilisé pour les deux .NET Framework 2.0 et .NET Framework 3.5 est CLR 2.0. En conséquence de cela, il y était pas nécessaire dans les deux précédents cadre de communiqués de diviser le GAC. Le problème de la rupture plus (dans ce cas, .NET 2.0) applications refait surface en Net Framework 4.0 à l' qui point CLR 4.0. Par conséquent, pour éviter les problèmes d'interférences entre CLR CLR 2.0 et 4.0, le GAC est maintenant divisé en privé Cdc pour chaque moment de l'exécution.
Comme le CLR est mis à jour dans les versions futures, vous pouvez vous attendre à la même chose. Si seulement la langue change, alors vous pouvez utiliser le même GAC.
Jasl
Points
810
Je voulais aussi savoir pourquoi les 2 GAC et constaté ce qui suit explication par Mark Miller dans la section des commentaires de .NET 4.0 a 2 Global Assembly Cache (GAC):
Mark Miller a dit... Juin 28, 2010 12:13 PM
Merci pour le post. "Les problèmes d'interférences" a été intentionnellement vague. Au moment de la l'écriture, les questions étaient toujours en cours une enquête, mais il était clair qu'il y ont cassé plusieurs scénarios.
Par exemple, certaines applications utilisent Assembly.LoadWithPartialName à charge la version la plus récente d'une assemblée. Si la version la plus récente a été compilé avec l' v4, puis une v2 (3.0 ou 3.5) app pas de charge, et l'application se bloque, même si il y avait une version qui aurait travaillé. À l'origine, nous partitionné le GAC sous emplacement d'origine, mais qui a causé quelques problèmes avec la mise à jour de windows les scénarios. Ces deux impliqués code qui avait déjà livré, donc nous nous sommes déplacés notre (version partitionné GAC un autre endroit.
Cela ne devrait pas avoir d'impact pour la plupart les applications, et ne pas ajouter de tout le fardeau de l'entretien. Les deux endroits ne doit être consulté ou modifié à l'aide de la maternelle GAC Api, qui traite de l' avec le partitionnement comme prévu. L' les endroits où ce n'surface sont grâce à des Api qui exposent les chemins de le GAC comme GetCachePath, ou l'examen de la trajectoire de mscorlib chargé en code managé.
Il est intéressant de noter que nous avons modifié le GAC les endroits où nous avons publié v2 quand nous avons présenté l'architecture comme une partie de l'identité de l'assembly. Ceux ajouté GAC_MSIL, GAC_32, et GAC_64, bien que toujours en vertu de %windir%\assembly. Malheureusement, c' n'est pas une option pour cette version.
Espérons qu'il aidera les futurs lecteurs.
Hans Passant
Points
475940
Il ne fait pas beaucoup de sens, l'original de la GAC a déjà été tout à fait capable de stocker les différentes versions des assemblées. Et il y a peu de raisons de supposer un programme déjà accidentellement de référence de la mauvaise assemblée, tous les .NET 4 assemblées eu l' [AssemblyVersion] heurté à 4.0.0.0. Le nouveau processus de side-by-side fonctionnalité ne devrait pas changer cette situation.
Ma conjecture: il y avait déjà trop .Projets NET qui a brisé le "plus jamais référence à quelque chose dans le GAC directement de la règle". Je l'ai vu faire sur ce site à plusieurs reprises.
Un seul moyen pour éviter la rupture de ces projets: déplacer le GAC. En arrière-compat est sacré chez Microsoft.
