为什么我不应该使用 GAC？
stackoverflow 上提出了一些问题，例如 使用 GAC 的优点和缺点 以及何时以及何时不安装到 GAC 中？ 并且有几个人在 网页expamle。 对于不使用 GAC，我找不到任何令人信服的论据。 我确信我很天真，但使用 GAC 似乎比不使用它有更多好处（例如性能和版本控制问题）。
为什么我不应该使用 GAC？
There have been a few questions asked along this line stackoverflow such as
What are the advantages and disadvantages of using the GAC
and When and when-not to install into the GAC? and a few people have asked it on the
web expamle. I can't any convincing arguments for not using the GAC. I am sure I am being naive but it seams like there are more benefits (such as performance and version control issues) to using the GAC then not using it.
Why should I NOT use the GAC?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
Chris Sells 可能给出了避开 GAC 的最佳理由，您可以：
Chris Sells gives probably the best reason for avoiding the GAC where you can:
我们的应用程序在任何给定时间都加载了 50 多个 .NET 程序集，并且我们不使用 GAC。 我认为，如果您必须同时运行应用程序的多个版本，并且每个版本都需要加载同一共享库的不同版本，那么 GAC 是最有用的。
即使这样，如果两个应用程序版本位于不同的目录中，那么只要将它们的二进制文件分开，您仍然不需要 GAC。
我一直觉得它对于制作 SDK/API 的人来说要有用得多，因为不同版本的 SDK 可以由多个应用程序加载并和谐相处。 因此，如果您也处于这种情况，那么 GAC 可能是有意义的。
有一些边缘案例需要 GAC（我认为 .NET COM+ 组件在某些情况下需要位于 GAC 中），但我认为这些只占案例的一小部分。
We have an application that has 50+ .NET assemblies loaded at any given time and we do not use the GAC. I think the GAC is most useful if you have to have multiple versions of your application running at one time, each of which needs to load a different version of the same shared library.
Even then, if the two application versions are in different directories then as long as you keep their binaries separate you still don't need the GAC.
I've always felt it is far more useful for someone that makes an SDK/API, where different versions of their SDK can be loaded by multiple applications and live in harmony. So if you are in this boat then the GAC may make sense.
There are some fringe cases that require the GAC (I think .NET COM+ components need to be in the GAC in some cases), but I think those are a small percentage of the cases.
如果您希望减少对应用程序的侵入性部署。 通过仅安装在应用程序目录中，您可以非常轻松地复制部署和清理。
If you want a less intrusive deployment of your application. By only installing in your application directory you can copy deploy and clean up very easily.
如果您有一个资源密集型的小型应用程序，那么我不想将文件安装到 GAC 中。
它将创建另一个依赖项，我需要在卸载时检查它，并且过去对滥用注册表的程序表达了很多悲痛。
调试/维护也会更容易一些，因为您可以轻松验证所有适当的库是否都位于应用程序的可执行路径中。
If you have a small application that is not that resource intensive, then I wouldn't want to install files into the GAC.
It would create another dependency that I would need to check for in my uninstall and there has been a lot of grief expressed in the past about programs that abuse the registry.
It would also be a little easier for debugging/maintenance in that you could easily verify that all the appropriate libraries are in the executable path of the application.
我问过类似的问题（我曾经真的需要使用全局程序集缓存 (GAC)？）
最好的答案是“GAC 仅在您注册要重用的库时才有用。”
换句话说，如果您不打算在不同应用程序之间共享库，则不要使用它。
I asked something similar (Do I ever really need to use the Global Assembly Cache (GAC)?)
The best answer was that "The GAC is only useful if you register libraries which you're going to reuse."
In other words, don't use it if you are not going to share libraries between different applications.
广汽集团有什么用？
i) 您可以在计算机上存储同一程序集的多个版本并并行执行它们。
ii) 将相同的程序集存储在机器上的多个位置会额外使用不需要的存储空间。 将它们保留在一个位置可以降低这一成本。
iii) 在一台机器上提供程序集变得更简单，因为您只需更新一个位置（GAC），而不是搜索存储在一台机器上的程序集的多个实例。
What is the use of GAC?
i) You can store multiple versions of the same assembly on a machine and execute them side by side.
ii) Store the same assemblies in multiple locations on a machine uses additionally unneeded storage. Keeping them in one location reduces this cost.
iii) Serving assemblies on a machine becomes simpler because you only have to update one location (the GAC) rather than searching for multiple instances of an assembly stored on a machine.
有时，在托管网站上，您无法控制 GAC，并且某些托管提供商不允许您将任何程序集安装到 GAC 中。 我以前遇到过这个问题，这是一个巨大的痛苦。
Sometimes on hosted websites you don't have control over the GAC, and some hosting providers won't allow you to install any assemblies into the GAC. I have run into this before and it's a huge pain.