.NET 4.0有一个新的GAC，为什么？
%windir%\Microsoft.NET\assembly\是新的GAC 。 这是否意味着我们必须pipe理两个GAC，一个用于.NET 2.0-3.5应用程序，另一个用于.NET 4.0应用程序？
问题是，为什么？
是的，因为有2个不同的全局程序集caching（GAC），您将不得不分别pipe理它们中的每一个。
在.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中有关4.0中的GAC更改的以下信息。
例如，如果.NET 1.1和.NET 2.0共享相同的GAC，则从此共享GAC加载程序集的.NET 1.1应用程序可能会获得.NET 2.0程序集，从而打破了.NET 1.1应用程序
用于.NET Framework 2.0和.NET Framework 3.5的CLR版本是CLR 2.0。 因此，在前两个框架版本中，不需要拆分GAC。 CLR 4.0发布的时候，在Net Framework 4.0中，破旧的（在这个例子中是.NET 2.0）应用程序重新出现了。 因此，为了避免CLR 2.0和CLR 4.0之间的干扰问题，GAC现在分为每个运行时的专用GAC。
由于CLR在未来版本中更新，您可以期待同样的事情。 如果只有语言改变，那么您可以使用相同的GAC。
我也想知道为什么2 GAC在.NET 4.0的注释部分中findMark Miller的以下解释，其中 有2个全局程序集caching（GAC） ：
马克·米勒说… 2010年6月28日12:13 PM
感谢您的post。 “干扰问题”故意含糊不清。 在撰写本文时，这些问题仍在调查中，但很明显有几个破碎的情况。
例如，某些应用程序使用Assemby.LoadWithPartialName加载程序集的最高版本。 如果最高版本是使用v4编译的，那么v2（3.0或3.5）应用程序无法加载它，即使存在可以工作的版本，应用程序也会崩溃。 最初，我们将GAC划分到原来的位置，但是这导致了Windows升级场景的一些问题。 这两个都涉及已经发货的代码，所以我们将我们的（版本分区的GAC）移到另一个地方。
这对大多数应用程序不应该有任何影响，并且不会增加任何维护负担。 只能使用原生GAC API访问或修改这两个位置，这些API会按预期处理分区。 这些表面上的地方是通过暴露GACpath的API（例如GetCachePath），或者检查加载到托pipe代码中的mscorlib的path。
值得注意的是，当我们发布v2时，我们也修改了GAC位置，当我们将体系结构作为程序集标识的一部分引入时。 那些添加了GAC_MSIL，GAC_32和GAC_64，虽然都在％windir％\ assembly下。 不幸的是，这不是这个版本的select。
希望它有助于未来的读者。
这并没有多大意义，原来的GAC已经能够存储不同版本的程序集了。 而且没有什么理由认为一个程序会偶然引用错误的程序集，所有的.NET 4程序集都将[AssemblyVersion]碰到了4.0.0.0。 新的进程内并行function不应该改变这一点。
我的猜测是：那里已经有太多的.NET项目打破了“从不直接引用GAC中的任何东西”的规则。 我已经看过几次这个网站。
避免打破这些项目只有一个办法：移动GAC。 Back-compat在微软是神圣的。
