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

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 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.

源

Why?

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

请参见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 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.

随着CLR在未来版本中的更新，您可以期待同样的事情。如果只是语言改变了，那么你可以使用相同的GAC。

这没有什么意义，最初的GAC已经能够存储不同版本的程序集。没有什么理由假设程序会不小心引用错误的程序集，所有。net 4程序集都将[AssemblyVersion]提升到4.0.0.0。新的进程内并排特性不应该改变这一点。

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

要避免破坏这些项目，只有一个办法:转移GAC。在微软，竞争是神圣的。

我也想知道为什么2 GAC，并在。net 4.0的评论区找到了Mark Miller的以下解释:

Mark Miller said... June 28, 2010 12:13 PM 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. 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. 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.

希望对以后的读者有所帮助。