重新审视GAC安装

Question

这个问题我知道，但我似乎无法找到满意的答案。

汇编应该在GAC中吗？这些问题：when-and-when-not-to-install-into-the-gac和What are the advantages and disadvantages of using the GAC正好解决了这个问题，但答案非常多，“建议......”或“你应该......”。为什么???

很多GAC反对的博客似乎都是从5/6年前开始的，当时.Net的明星开始崛起。我们现在还在吗？当然，DLL-Hell已成为过去，GAC支持并排安装不同版本的“相同”组件？

让我充实我的担忧。我们有越来越多的网络应用程序（到目前为止已有5个）。它们的核心是通过API调用和数据库扩展对第三方应用程序的扩展。因此，显然，所有这些应用程序共享大量共同的代码，我们正在开发一组新的核心共享库，以提高我们的质量，可维护性等。

当然，我希望这个共享功能安装一次并共享。所有关于打开维护噩梦的争论似乎都是基于一些不良纪律的世界。如果你打破了ABI，那么碰撞AssemblyVersion就足以让现有的应用程序保持正常运行。

GAC真的是一个不知情的蜜罐吗？我天真吗？当我驳斥“XCopy”安装失败的论点时，我是不是觉得不必要的苛刻？或者它是否有点“宗教”，我应该选择看似正确的东西？

感谢您帮助我看到了光明。

丹

Answer 1

我个人从未直接在GAC中安装任何程序集（除了纯粹的学术练习）。我之前听说过关于使用从几个应用程序访问的集中位置的程序集的说法，虽然这看起来有点吸引人，但个人而言，这不值得我花时间。如今计算机配备了320GB的硬盘空间......即使它被复制了5次，我的160K组装也不会有任何影响。 （当然，有些人可能会争辩“公地问题”......你知道：“如果每个开发人员都这么想......”，但我离题了）。我选择不这样做的主要原因是因为一个特定的应用程序可能以某种方式依赖于程序集，而另一个应用程序可能依赖于另一种方式。虽然在理想的世界中，对这个程序集的更新永远不应该影响依赖它的应用程序，实际上，它经常会这样做。如果我正在修复程序集的问题，因为特定的应用程序存在问题，我无意中影响了依赖于该特定程序集的其他应用程序。另一方面，有些人可能认为这种情况使我们成为更好的程序员，并使我们的GAC共享程序集更具防弹性。这很好，但我作为程序员的工作并不是为了使自己成为一名更好的程序员，而是为了编写有效的程序，这样做，我将成为一名更好的程序员。

那么我的投票是什么？远离GAC。让每个应用程序都依赖于它们所依赖的组件版本。一个应用程序在该程序集中暴露的错误可能永远不会出现在其他应用程序中，因为它们以不同的方式使用程序集，因此请保留它们，并且每次修补共享DLL时都不必回归测试5个不同的应用程序。

Answer 2

我使用以下弱策略 使用GAC - 当不同的程序使用共享程序集+版本控制时 请勿使用GAC - 始终。

欢迎任何评论。