有很多问题沿着这一行堆栈溢出问题，例如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％的应用程序，无论你是否知道，都不要破坏。这是一个非常棒的责任，需要MS数百人年.NET Framework的每个新版本。即使有数百个人年的测试，我们仍然不能总是正确的。如果这是你愿意忍受的测试责任，我很钦佩你。就个人而言，我没有道德的毅力来承担这种负担。
我们有一个应用程序，在任何给定时间加载了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中。我之前遇到过这种情况，这是一个巨大的痛苦。