简体繁体 English

.NET 4.0有一个新的GAC，为什么？

[英].NET 4.0 has a new GAC, why?

原文 2010-04-17 22:43:00 1 3 .net/ .net-4.0/ gac

%windir%\\Microsoft.NET\\assembly\\ is the new GAC . %windir%\\Microsoft.NET\\assembly\\是新的GAC 。 Does it mean now we have to manage two GACs, one for .NET 2.0-3.5 applications and the other for .NET 4.0 applications? 这是否意味着现在我们必须管理两个GAC，一个用于.NET 2.0-3.5应用程序，另一个用于.NET 4.0应用程序？

The question is, why? 问题是，为什么？

3 个解决方案

Yes since there are 2 distinct Global Assembly Cache (GAC), you will have to manage each of them individually. 是的，因为有2个不同的全局程序集缓存（GAC），您必须单独管理它们中的每一个。

In .NET Framework 4.0, the GAC went through a few changes. 在.NET Framework 4.0中，GAC经历了一些更改。 The GAC was split into two, one for each CLR. GAC分为两个，每个CLR一个。

The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. 用于.NET Framework 2.0和.NET Framework 3.5的CLR版本是CLR 2.0。 There was no need in the previous two framework releases to split GAC. 前两个框架版本中没有必要拆分GAC。 The problem of breaking older applications in Net Framework 4.0. 在Net Framework 4.0中破坏旧应用程序的问题。

To avoid issues between CLR 2.0 and CLR 4.0 , the GAC is now split into private GAC's for each runtime.The main change is that CLR v2.0 applications now cannot see CLR v4.0 assemblies in the GAC. 为了避免CLR 2.0和CLR 4.0之间的问题，GAC现在分为每个运行时的私有GAC。主要的变化是CLR v2.0应用程序现在无法在GAC中看到CLR v4.0程序集。

Source 资源

Why? 为什么？

It seems to be because there was a CLR change in .NET 4.0 but not in 2.0 to 3.5. 这似乎是因为.NET 4.0中存在CLR更改，而不是2.0到3.5。 The same thing happened with 1.1 to 2.0 CLR. 1.1到2.0 CLR也发生了同样的事情。 It seems that the GAC has the ability to store different versions of assemblies as long as they are from the same CLR. 似乎GAC能够存储不同版本的程序集，只要它们来自同一个CLR。 They do not want to break old applications. 他们不想破坏旧的应用程序。

See the following information in MSDN about the GAC changes in 4.0 . 请参阅MSDN中有关4.0中GAC更改的以下信息。

For example, if both .NET 1.1 and .NET 2.0 shared the same GAC, then a .NET 1.1 application, loading an assembly from this shared GAC, could get .NET 2.0 assemblies, thereby breaking the .NET 1.1 application 例如，如果.NET 1.1和.NET 2.0共享相同的GAC，则从此共享GAC加载程序集的.NET 1.1应用程序可能会获得.NET 2.0程序集，从而破坏.NET 1.1应用程序

The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. 用于.NET Framework 2.0和.NET Framework 3.5的CLR版本是CLR 2.0。 As a result of this, there was no need in the previous two framework releases to split the GAC. 因此，前两个框架版本中没有必要拆分GAC。 The problem of breaking older (in this case, .NET 2.0) applications resurfaces in Net Framework 4.0 at which point CLR 4.0 released. 破解旧版本（在本例中为.NET 2.0）应用程序的问题在Net Framework 4.0中重新出现，此时CLR 4.0已发布。 Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime. 因此，为了避免CLR 2.0和CLR 4.0之间的干扰问题，GAC现在分为每个运行时的私有GAC。

As the CLR is updated in future versions you can expect the same thing. 随着CLR在未来版本中的更新，您可以期待同样的事情。 If only the language changes then you can use the same GAC. 如果只有语言更改，那么您可以使用相同的GAC。

I also wanted to know why 2 GAC and found the following explanation by Mark Miller in the comments section of .NET 4.0 has 2 Global Assembly Cache (GAC) : 我还想知道为什么2 GAC并且发现Mark Miller在.NET 4.0的评论部分中有以下解释有2个全局程序集缓存（GAC）：

Mark Miller said... June 28, 2010 12:13 PM 马克米勒说... 2010年6月28日下午12:13

Thanks for the post. 谢谢你的帖子。 "Interference issues" was intentionally vague. “干扰问题”故意模糊不清。 At the time of writing, the issues were still being investigated, but it was clear there were several broken scenarios. 在撰写本文时，问题仍在调查中，但很明显有几个破碎的情景。

For instance, some applications use Assemby.LoadWithPartialName to load the highest version of an assembly. 例如，某些应用程序使用Assemby.LoadWithPartialName来加载程序集的最高版本。 If the highest version was compiled with v4, then a v2 (3.0 or 3.5) app could not load it, and the app would crash, even if there were a version that would have worked. 如果最高版本是使用v4编译的，那么v2（3.0或3.5）应用程序无法加载它，并且应用程序会崩溃，即使有一个版本可行。 Originally, we partitioned the GAC under it's original location, but that caused some problems with windows upgrade scenarios. 最初，我们在其原始位置下划分了GAC，但这导致了Windows升级方案的一些问题。 Both of these involved code that had already shipped, so we moved our (version-partitioned GAC to another place. 这两个都涉及已经发布的代码，因此我们将（版本分区的GAC）移动到另一个地方。

This shouldn't have any impact to most applications, and doesn't add any maintenance burden. 这不会对大多数应用程序产生任何影响，也不会增加任何维护负担。 Both locations should only be accessed or modified using the native GAC APIs, which deal with the partitioning as expected. 只应使用本机GAC API访问或修改这两个位置，本地GAC API按预期处理分区。 The places where this does surface are through APIs that expose the paths of the GAC such as GetCachePath, or examining the path of mscorlib loaded into managed code. 它所代表的地方是通过API公开GAC的路径（如GetCachePath），或检查加载到托管代码中的mscorlib的路径。

It's worth noting that we modified GAC locations when we released v2 as well when we introduced architecture as part of the assembly identity. 值得注意的是，当我们将架构作为装配标识的一部分引入时，我们在发布v2时修改了GAC位置。 Those added GAC_MSIL, GAC_32, and GAC_64, although all still under %windir%\\assembly. 那些添加了GAC_MSIL，GAC_32和GAC_64，尽管它们仍然在％windir％\\ assembly下。 Unfortunately, that wasn't an option for this release. 不幸的是，这不是这个版本的选项。

Hope it helps future readers. 希望它能帮助未来的读者。

It doesn't make a lot of sense, the original GAC was already quite capable of storing different versions of assemblies. 它没有多大意义，原始的GAC已经能够存储不同版本的程序集。 And there's little reason to assume a program will ever accidentally reference the wrong assembly, all the .NET 4 assemblies got the [AssemblyVersion] bumped up to 4.0.0.0. 并且没有理由认为程序会偶然引用错误的程序集，所有.NET 4程序集都会使[AssemblyVersion]达到4.0.0.0。 The new in-process side-by-side feature should not change this. 新的进程内并排功能不应改变这一点。

My guess: there were already too many .NET projects out there that broke the "never reference anything in the GAC directly" rule. 我的猜测：已经有太多的.NET项目打破了“永远不会引用GAC中的任何内容”规则。 I've seen it done on this site several times. 我已经在这个网站上看了好几次。

Only one way to avoid breaking those projects: move the GAC. 只有一种方法可以避免破坏这些项目：移动GAC。 Back-compat is sacred at Microsoft. Back-compat在微软是神圣的。