%windir%\Microsoft.NET\ assembly\ 是新的 GAC 。这是否意味着现在我们必须管理两个 GAC，一个用于 .NET 2.0-3.5 应用程序，另一个用于 .NET 4.0 应用程序？
问题是，为什么？
%windir%\Microsoft.NET\assembly\ is the new 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?
The question is, why?
发布评论
评论（4）
是的，因为有 2 个不同的全局程序集缓存 (GAC)，您必须单独管理它们。
来源
为什么？
看来这是因为 .NET 4.0 中发生了 CLR 更改，但 2.0 到 3.5 中没有更改。 1.1 到 2.0 CLR 也发生了同样的事情。看来 GAC 能够存储不同版本的程序集，只要它们来自同一个 CLR。他们不想破坏旧的应用程序。
请参阅 MSDN 中有关 4.0 中的 GAC 更改的信息。
随着 CLR 在未来版本中的更新，您可以期待同样的事情。如果仅语言发生变化，那么您可以使用相同的 GAC。
Yes since there are 2 distinct Global Assembly Cache (GAC), you will have to manage each of them individually.
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.
See the following information in MSDN about the GAC changes in 4.0.
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.
我还想知道为什么 2 GAC 并发现以下 Mark Miller 的解释，位于 .NET 4.0 有 2 个全局程序集缓存 (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):
Hope it helps future readers.
这没有多大意义，原来的 GAC 已经能够存储不同版本的程序集了。并且没有理由假设程序会意外引用错误的程序集，所有 .NET 4 程序集的 [AssemblyVersion] 都已升至 4.0.0.0。新的进程内并排功能不应改变这一点。
我的猜测：已经有太多的 .NET 项目违反了“永远不要直接引用 GAC 中的任何内容”规则。我已经在这个网站上看到过好几次了。
避免破坏这些项目的唯一方法是：移动 GAC。向后兼容对于微软来说是神圣的。
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.
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.
Only one way to avoid breaking those projects: move the GAC. Back-compat is sacred at Microsoft.
在 .NET Framework 4.0 中，GAC 经历了一些更改。 GAC 被分成两部分，每个 CLR 一个。
用于 .NET Framework 2.0 和 .NET Framework 3.5 的 CLR 版本是 CLR 2.0。前两个框架版本中无需拆分 GAC。 Net Framework 4.0 中破坏旧应用程序的问题。
为了允许较旧的（32 位、单线程）应用程序运行，同时也允许较新的（64 位，可能是多线程）应用程序运行并避免 CLR 2.0 和 CLR 4.0 之间的问题，GAC 需要分为每个运行时的私有 GAC。主要变化是，由于线程安全问题，CLR v2.0 应用程序现在无法在 GAC 中看到 CLR v4.0 程序集。
这种拆分还允许对整个 .Net 进行版本升级/更新，而不会牺牲向后兼容性。
In .NET Framework 4.0, the GAC went through a few changes. The GAC was split into two, one for each 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.
To allow older (32-bit, single-threaded) apps to function, while also allowing newer (64-bit, possibly multi-threaded) ones to work AND avoiding issues between CLR 2.0 and CLR 4.0, the GAC needed to be 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, because of Thread-Safety concerns.
This split also allows for version upgraded/updates for .Net as a whole, without sacrificing backwards compatibility.