在stackoverflow这条线上有几个问题，例如 What are the advantages and disadvantages of using the GAC 和When and when-not to install into the GAC? 和一些人在 网络expamle。对于不使用 GAC，我没有任何令人信服的论据。我确信我很天真，但似乎使用 GAC 比不使用它有更多好处（例如性能和版本控制问题）。
为什么我不应该使用 GAC？
【问题讨论】：
Chris Sells 可能会提供the best reason for avoiding the GAC，您可以：
这归结为任何用于更新的共享点，无论是 COM CLSID、windows\system32 还是 GAC，都是危险的，应该避免。这就是为什么首选的 .NET 部署方案是“xcopy 部署”的原因，即拥有您自己测试的每个 DLL 的私有副本，并与应用程序的其余部分一起部署。
“啊哈！”你说。 “GAC 支持程序集的多个版本！当 foo.dll 更新到 v1.1 时，v1.0 就在它旁边，这样您的应用程序不会崩溃！”当然，这绝对是真的。但如果是这样，你又何必在意呢？我的意思是，如果有一个新的程序集可用，但你的应用程序没有选择它，它有什么不同？
“再次啊哈！你说。“我可以将发布者政策与我的程序集一起放入 GAC，以便应用程序自动更新！”这也是正确的，但现在，就像任何在旧的机器范围的代码替换策略中，你肩负着一项艰巨的责任：确保接近 0% 的应用程序，无论你是否知道，都不会崩溃。这是一项了不起的责任，并且.NET Framework 的每个新版本都需要 MS 数百人年的时间。即使进行了数百人年的测试，我们仍然不能总是做对。如果这是你的测试责任愿意和你一起生活，我很佩服你。就我个人而言，我没有道德上的毅力来承担这个负担。
【讨论】：
我们的应用程序在任何给定时间都加载了 50 多个 .NET 程序集，并且我们不使用 GAC。如果您必须同时运行多个版本的应用程序，我认为 GAC 最有用，每个版本都需要加载同一共享库的不同版本。
即便如此，如果两个应用程序版本位于不同的目录中，那么只要您将它们的二进制文件分开，您仍然不需要 GAC。
我一直觉得对于制作 SDK/API 的人来说它更有用，因为他们的不同版本的 SDK 可以由多个应用程序加载并和谐相处。因此，如果您在这条船上，那么 GAC 可能是有意义的。
有一些边缘案例需要 GAC（我认为 .NET COM+ 组件在某些情况下需要在 GAC 中），但我认为这些只是一小部分案例。
【讨论】：
如果您希望对应用程序进行较少干扰的部署。通过仅安装在您的应用程序目录中，您可以非常轻松地复制部署和清理。
【讨论】：
如果您有一个不占用大量资源的小型应用程序，那么我不想将文件安装到 GAC 中。
它会创建另一个依赖项，我需要在卸载时检查它，并且过去曾对滥用注册表的程序表示过很多悲痛。
调试/维护也会更容易一些，因为您可以轻松验证所有适当的库是否都在应用程序的可执行路径中。
【讨论】：
我问过类似的问题 (Do I ever really need to use the Global Assembly Cache (GAC)?)
最佳答案是“GAC 仅在您注册要重用的库时才有用。”
换句话说，如果您不打算在不同应用程序之间共享库，请不要使用它。
【讨论】：
GAC 有什么用？
i) 您可以在一台机器上存储同一个程序集的多个版本并并排执行它们。 ii) 将相同的组件存储在机器上的多个位置会使用额外的不需要的存储空间。将它们放在一个位置可以降低成本。 iii) 在机器上提供程序集变得更简单，因为您只需更新一个位置（GAC），而不是搜索存储在机器上的程序集的多个实例。
【讨论】：
有时在托管网站上，您无法控制 GAC，并且某些托管服务提供商不允许您将任何程序集安装到 GAC 中。我以前遇到过这种情况，这是一个巨大的痛苦。
【讨论】：