.NET4.0有了一个新的GAC，为什么?-.NET4.0hasanewGAC,why?

177  

Yes since there are 2 distinct Global Assembly Cache (GAC), you will have to manage each of them individually.

是的，因为有两个不同的全局程序集缓存(GAC)，所以您必须分别管理它们。

In .NET Framework 4.0, the GAC went through a few changes. The GAC was split into two, one for each CLR.

在。net Framework 4.0中，GAC经历了一些变化。GAC被分成两部分，每一部分对应一个CLR。

The CLR version used for both .NET Framework 2.0 and .NET Framework 3.5 is CLR 2.0. There was no need in the previous two framework releases to split GAC. The problem of breaking older applications in Net Framework 4.0.

用于。net Framework 2.0和。net Framework 3.5的CLR版本是CLR 2.0。在之前的两个框架版本中不需要拆分GAC。在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. The same thing happened with 1.1 to 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. They do not want to break old applications.

这似乎是因为。net 4.0中有CLR的变化，而不是2.0到3.5。同样的事情也发生在1.1到2.0的CLR上。GAC似乎可以存储不同版本的程序集，只要它们来自同一个CLR。他们不想破坏旧的应用程序。

See the following information in MSDN about the GAC changes in 4.0.

关于4.0中GAC的变化，请参阅MSDN中的以下信息。

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，那么.NET 1.1应用程序从这个共享的GAC加载程序集，就可以得到.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. As a result of this, there was no need in the previous two framework releases to split the 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. Hence, to avoid interference issues between CLR 2.0 and CLR 4.0, the GAC is now split into private GACs for each runtime.

用于。net Framework 2.0和。net Framework 3.5的CLR版本是CLR 2.0。因此，在前两个框架版本中不需要拆分GAC。打破旧的(在本例中是。Net 2.0)应用程序的问题在netframework 4.0中重新出现，CLR 4.0在那时发布。因此，为了避免CLR 2.0和CLR 4.0之间的干扰问题，GAC现在被分割为每个运行时的私有GACs。

As the CLR is updated in future versions you can expect the same thing. If only the language changes then you can use the same GAC.

由于CLR在将来的版本中被更新，您可以期待同样的事情。如果语言改变了，那么您可以使用相同的GAC。

66  

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，在。net 4.0的评论部分，Mark Miller给出了如下解释:

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. 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. Originally, we partitioned the GAC under it's original location, but that caused some problems with windows upgrade scenarios. Both of these involved code that had already shipped, so we moved our (version-partitioned GAC to another place.

例如，一些应用程序使用Assemby。LoadWithPartialName加载程序集的最高版本。如果最高版本是用v4编译的，那么v2(3.0或3.5)应用程序就无法加载它，即使有一个版本可以运行，应用程序也会崩溃。最初，我们在它的原始位置对GAC进行分区，但是这在windows升级场景中造成了一些问题。这两个都涉及到已经发布的代码，因此我们将(版本分区的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. 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.

这应该不会对大多数应用程序产生任何影响，也不会增加任何维护负担。应该只使用本地GAC api访问或修改这两个位置，这些api按照预期处理分区。这些地方是通过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. Those added GAC_MSIL, GAC_32, and GAC_64, although all still under %windir%\assembly. Unfortunately, that wasn't an option for this release.

值得注意的是，我们在发布v2时修改了GAC位置，当我们将体系结构作为程序集标识的一部分引入时也是如此。它们添加了GAC_MSIL、GAC_32和GAC_64，尽管它们仍然在%windir%\程序集之下。不幸的是，这个版本没有这个选项。

Hope it helps future readers.

希望它能帮助未来的读者。

63  

It doesn't make a lot of sense, the original GAC was already quite capable of storing different versions of assemblies. 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. The new in-process side-by-side feature should not change this.

这没有多大意义，最初的GAC已经能够存储不同版本的程序集。并且没有理由假设一个程序会偶然地引用错误的程序集，所有。net 4程序集的[汇编版本]都增加到4.0.0.0。新的并行进程特性不应该改变这一点。

My guess: there were already too many .NET projects out there that broke the "never reference anything in the GAC directly" rule. I've seen it done on this site several times.

我的猜测是:已经有太多的。net项目打破了“绝对不要直接引用GAC中的任何东西”的规则。我在这个网站上见过好几次。

Only one way to avoid breaking those projects: move the GAC. Back-compat is sacred at Microsoft.

只有一种方法可以避免破坏这些项目:移动GAC。反编译在微软是神圣的。