%windir%\Microsoft.NET\assembly\是新的GAC。这是否意味着现在我们必须管理两个GAC，一个用于.NET 2.0-3.5应用程序，另一个用于.NET 4.0应用程序？
问题是，为什么？
答案 0 :(得分：180)
是的，因为有2个不同的全局程序集缓存（GAC），您必须单独管理它们。
在.NET Framework 4.0中，GAC经历了一些更改。 GAC被分为两个，每个CLR一个。
用于.NET Framework 2.0和.NET Framework 3.5的CLR版本是CLR 2.0。前两个框架版本中没有必要拆分GAC。在Net Framework 4.0中破坏旧应用程序的问题。
为了避免CLR 2.0和CLR 4.0之间的问题，GAC现在分为每个运行时的私有GAC。主要的变化是CLR v2.0应用程序现在无法在GAC中看到CLR v4.0程序集。
<强>为什么吗
似乎是因为.NET 4.0中存在CLR更改，而不是2.0到3.5。 1.1到2.0 CLR也发生了同样的事情。似乎GAC能够存储不同版本的程序集，只要它们来自同一个CLR。他们不想破坏旧的应用程序。
请参阅MSDN about the GAC changes in 4.0中的以下信息。
例如，如果.NET 1.1和.NET 2.0共享相同的GAC，则从此共享GAC加载程序集的.NET 1.1应用程序可能会获得.NET 2.0程序集，从而破坏.NET 1.1应用程序< / p>
用于.NET的CLR版本 Framework 2.0和.NET Framework 3.5 是CLR 2.0。因此，有 在前两次没有必要 框架版本将拆分GAC。 打破老年人的问题（在此 case，.NET 2.0）应用程序 在Net Framework 4.0中重新出现 CLR 4.0发布了哪一点。因此， 避免之间的干扰问题 CLR 2.0和CLR 4.0，现在是GAC 每个人分成私人GAC 运行时。
随着CLR在未来版本中更新，您可以期待同样的事情。如果只有语言更改，那么您可以使用相同的GAC。
答案 1 :(得分：67)
我还想知道为什么2 GAC并在explanation by Mark Miller的comments section中找到以下.NET 4.0 has 2 Global Assembly Cache (GAC)：
马克米勒说...... 2010年6月28日下午12:13
谢谢 这篇文章。 “干扰问题”是 故意模糊。在那个时间 写作，问题仍然存在 调查，但很明显 是几个破碎的场景。
例如，某些应用程序使用 要加载的Assemby.LoadWithPartialName 装配的最高版本。如果 编译的最高版本 v4，然后一个v2（3.0或3.5）应用程序可以 没有加载它，应用程序会崩溃， 即使有版本 本来会有用的。原来，我们 将GAC划分为它 原来的位置，但那造成的 Windows升级的一些问题 场景。这两个都涉及代码 已经发货，所以我们搬了 我们（版本划分的GAC到 另一个地方。
这对大多数人不会产生任何影响 应用程序，并不添加任何 维修负担。这两个地方 应该只能访问或修改 使用原生GAC API进行处理 按预期分区。该 这表面的地方是 通过暴露路径的API GAC，如GetCachePath，或 检查加载的mscorlib的路径 进入托管代码。
值得注意的是，我们修改了GAC 我们发布v2时的位置 当我们介绍架构时 部分标识的一部分。那些 添加了GAC_MSIL，GAC_32和GAC_64， 虽然都还在 ％WINDIR％\组件。不幸的是，那 不是这个版本的选项。
希望它能帮助未来的读者。
答案 2 :(得分：65)
它没有多大意义，原始的GAC已经能够存储不同版本的程序集。并且没有理由认为程序会偶然引用错误的程序集，所有.NET 4程序集都会使[AssemblyVersion]达到4.0.0.0。新的进程内并排功能不应改变这一点。
我的猜测：已经有太多的.NET项目打破了“永远不会引用GAC中的任何内容”规则。我已经多次在这个网站上看到它了。
只有一种方法可以避免破坏这些项目：移动GAC。 Back-compat在微软是神圣的。