沿着 stackoverflow 这条线提出了一些问题，例如 使用 GAC 的优点和缺点是什么 以及何时以及何时不安装到 GAC 中？并且有几个人在网络示例上问过它。对于不使用 GAC，我没有任何令人信服的论据。我确信我很天真，但似乎使用 GAC 比不使用它有更多好处（例如性能和版本控制问题）。
为什么我不应该使用 GAC？
Maudite
问问题
10343 次
7 回答
46
Chris Sells 给出了尽可能避免 GAC 的最佳理由：
这归结为任何用于更新的共享点，无论是 COM CLSID、windows\system32 还是 GAC，都是危险的，应该避免。这就是为什么首选的 .NET 部署方案是“xcopy 部署”的原因，即拥有您自己的每个 DLL 的私有副本，您可以将其与应用程序的其余部分一起测试和部署。
“啊哈！” 你说。“GAC 支持程序集的多个版本！当 foo.dll 更新到 v1.1 时，v1.0 就在它旁边，这样您的应用程序就不会中断！” 当然，这绝对是真的。但如果是这样，你又何必在意呢？我的意思是，如果有一个新的程序集可用，但您的应用程序没有选择它，它有什么区别？
“啊哈！，你说。“我可以将发布者策略与我的程序集一起放入 GAC，以便应用程序自动更新！ ，你要承担一项艰巨的责任：确保接近 0% 的应用程序，无论你是否知道，都不会崩溃。这是一项了不起的责任，需要 MS 数百人年才能完成.NET Framework 的每个新版本。即使进行了数百人年的测试，我们仍然无法始终正确。如果这是您愿意承担的测试责任，我很佩服您。就个人而言，我没有道德上的毅力来承担这个负担。
于 2009-02-11T21:04:33.533 回答
6
我们有一个应用程序在任何给定时间加载了 50 多个 .NET 程序集，并且我们不使用 GAC。如果您必须同时运行多个版本的应用程序，我认为 GAC 最有用，每个版本都需要加载同一共享库的不同版本。
即使那样，如果两个应用程序版本位于不同的目录中，那么只要您将它们的二进制文件分开，您仍然不需要 GAC。
我一直觉得它对于制作 SDK/API 的人来说更有用，因为他们的 SDK 的不同版本可以由多个应用程序加载并和谐相处。因此，如果您在这条船上，那么 GAC 可能是有意义的。
有一些边缘案例需要 GAC（我认为 .NET COM+ 组件在某些情况下需要在 GAC 中），但我认为这些只是一小部分案例。
于 2009-02-11T21:00:11.547 回答
3
如果您希望对应用程序进行较少干扰的部署。通过仅安装在您的应用程序目录中，您可以非常轻松地复制部署和清理。
于 2009-02-11T20:56:44.690 回答
2
如果您有一个不占用大量资源的小型应用程序，那么我不想将文件安装到 GAC 中。
它会创建另一个依赖项，我需要在卸载时检查它，并且过去曾对滥用注册表的程序表示过很多悲痛。
调试/维护也会更容易一些，因为您可以轻松验证所有适当的库是否都在应用程序的可执行路径中。
于 2009-02-11T20:57:45.563 回答
2
于 2009-02-11T21:19:26.447 回答
2
GAC有什么用？
i) 您可以在一台机器上存储同一个程序集的多个版本并并排执行它们。ii) 将相同的组件存储在机器上的多个位置使用额外的不需要的存储空间。将它们放在一个位置可以降低成本。iii) 在机器上提供程序集变得更简单，因为您只需更新一个位置（GAC），而不是搜索存储在机器上的程序集的多个实例。
于 2011-03-16T11:53:22.853 回答
1
有时在托管网站上，您无法控制 GAC，并且某些托管服务提供商不允许您将任何程序集安装到 GAC 中。我以前遇到过这种情况，这是一个巨大的痛苦。
于 2009-02-11T20:51:47.963 回答