%windir%\Microsoft.NET\assembly\是新的GAC。这是否意味着现在我们必须管理两个 GAC，一个用于.NET 2.0-3.5 应用程序，另一个用于.NET 4.0 应用程序？
%windir%\Microsoft.NET\assembly\
问题是，为什么？
是的，因为有 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，每个 runtime.The 主要变化是 CLR v2.0 应用程序现在无法在 GAC 中看到 CLR v4.0 程序集。
资源
为什么？
这似乎是因为.NET 4.0 中有 CLR 更改但 2.0 到 3.5 没有。同样的事情发生在 1.1 到 2.0 CLR。似乎 GAC 能够存储不同版本的程序集，只要它们来自同一个 CLR。他们不想破坏旧的应用程序。
请参阅有关 GAC 更改的 MSDN 4.0中的以下信息。
例如，如果.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。破坏旧的(在这种情况下，.NET 2.0)应用程序的问题在 Net Framework 4.0 中重新出现，此时 CLR 4.0 被释放。因此，为了避免 CLR 2.0 和 CLR 4.0 之间的干扰问题，GAC 现在被拆分为每个运行时的私有 GAC。
随着 CLR 在未来版本中的更新，您可以期待同样的事情。如果只有语言更改，那么您可以使用相同的 GAC。
我也想知道为什么 2 GAC 并在.NET 4.0 有 2 个全局程序集缓存(GAC)的评论部分中找到以下马克米勒的解释：
马克米勒说... 2010 年 6 月 28 日 12:13 PM
谢谢你的帖子。 “干扰问题”故意模糊不清。在撰写本文时，问题仍在调查中，但很明显有几个破碎的情景。
例如，某些应用程序使用 Assemby.LoadWithPartialName 来加载程序集的最高版本。如果最高版本是使用 v4 编译的，那么 v2(3.0 或 3.5)应用程序无法加载它，并且应用程序会崩溃，即使有一个版本可行。最初，我们在其原始位置下划分了 GAC，但这导致了 Windows 升级方案的一些问题。这两个都涉及已经发布的代码，所以我们将我们(version-partitioned GAC)移到另一个地方。
这不会对大多数应用程序产生任何影响，也不会增加任何维护负担。只应使用本机 GAC API 访问或修改这两个位置，本地 GAC API 按预期处理分区。它所代表的地方是通过 API 公开 GAC 的路径(如 GetCachePath)，或检查加载到托管代码中的 mscorlib 的路径。
值得注意的是，当我们将架构作为装配标识的一部分引入时，我们在发布 v2 时修改了 GAC 位置。那些添加了 GAC_MSIL，GAC_32 和 GAC_64，尽管它们仍然在％windir％\ assembly 下。不幸的是，这不是这个版本的选项。
希望它能帮助未来的读者。
它没有多大意义，原始的 GAC 已经能够存储不同版本的程序集。并且没有理由认为程序会不小心引用错误的程序集，所有.NET 4 程序集[11]都会升级到 4.0.0.0. 新的 in-process side-by-side 功能不应该改变这一点。
我的猜测：已经有太多的.NET 项目打破了“永远不会引用 GAC 中的任何内容”规则。我已经在这个网站上看了好几次。
只有一种方法可以避免破坏这些项目：移动 GAC。 Back-compat 在微软是神圣的。
3 回答
是的，因为有 2 个不同的全局程序集缓存(GAC)，您必须单独管理它们中的每一个。
用于.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，每个 runtime.The 主要变化是 CLR v2.0 应用程序现在无法在 GAC 中看到 CLR v4.0 程序集。
资源
为什么？
这似乎是因为.NET 4.0 中有 CLR 更改但 2.0 到 3.5 没有。同样的事情发生在 1.1 到 2.0 CLR。似乎 GAC 能够存储不同版本的程序集，只要它们来自同一个 CLR。他们不想破坏旧的应用程序。
请参阅有关 GAC 更改的 MSDN 4.0中的以下信息。
用于.NET Framework 2.0 和.NET Framework 3.5 的 CLR 版本是 CLR 2.0. 因此，前两个框架版本中没有必要拆分 GAC。破坏旧的(在这种情况下，.NET 2.0)应用程序的问题在 Net Framework 4.0 中重新出现，此时 CLR 4.0 被释放。因此，为了避免 CLR 2.0 和 CLR 4.0 之间的干扰问题，GAC 现在被拆分为每个运行时的私有 GAC。
随着 CLR 在未来版本中的更新，您可以期待同样的事情。如果只有语言更改，那么您可以使用相同的 GAC。
我也想知道为什么 2 GAC 并在.NET 4.0 有 2 个全局程序集缓存(GAC)的评论部分中找到以下马克米勒的解释：
谢谢你的帖子。 “干扰问题”故意模糊不清。在撰写本文时，问题仍在调查中，但很明显有几个破碎的情景。
例如，某些应用程序使用 Assemby.LoadWithPartialName 来加载程序集的最高版本。如果最高版本是使用 v4 编译的，那么 v2(3.0 或 3.5)应用程序无法加载它，并且应用程序会崩溃，即使有一个版本可行。最初，我们在其原始位置下划分了 GAC，但这导致了 Windows 升级方案的一些问题。这两个都涉及已经发布的代码，所以我们将我们(version-partitioned GAC)移到另一个地方。
这不会对大多数应用程序产生任何影响，也不会增加任何维护负担。只应使用本机 GAC API 访问或修改这两个位置，本地 GAC API 按预期处理分区。它所代表的地方是通过 API 公开 GAC 的路径(如 GetCachePath)，或检查加载到托管代码中的 mscorlib 的路径。
值得注意的是，当我们将架构作为装配标识的一部分引入时，我们在发布 v2 时修改了 GAC 位置。那些添加了 GAC_MSIL，GAC_32 和 GAC_64，尽管它们仍然在％windir％\ assembly 下。不幸的是，这不是这个版本的选项。
希望它能帮助未来的读者。
它没有多大意义，原始的 GAC 已经能够存储不同版本的程序集。并且没有理由认为程序会不小心引用错误的程序集，所有.NET 4 程序集[11]都会升级到 4.0.0.0. 新的 in-process side-by-side 功能不应该改变这一点。
我的猜测：已经有太多的.NET 项目打破了“永远不会引用 GAC 中的任何内容”规则。我已经在这个网站上看了好几次。
只有一种方法可以避免破坏这些项目：移动 GAC。 Back-compat 在微软是神圣的。