重新审视 GAC 安装答案

【问题标题】：Revisiting GAC Installations重新审视 GAC 安装
【发布时间】：2011-01-23 15:24:02
【问题描述】：

这个我知道，但我似乎找不到满意的答复。

程序集应该进入 GAC 吗？这些问题：when-and-when-not-to-install-into-the-gac 和What are the advantages and disadvantages of using the GAC，正是针对这些问题，但答案非常多是“建议……”或“你应该只……”。为什么？？？

许多反对 GAC 的博客似乎可以追溯到 5/6 年前，当时 .Net 的明星开始崛起。我们现在还在吗？随着 GAC 支持并排安装“相同”程序集的不同版本，DLL-Hell 肯定已成为过去？

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

当然，我希望这个共享功能安装一次并共享。所有关于开启维护噩梦的争论似乎都是基于一些缺乏纪律的世界。如果你破坏了 ABI，那么修改 AssemblyVersion 就足以让你现有的应用程序正常工作。

对于毫无戒心的人来说，GAC 真的是一个蜜饯吗？我是不是太天真了？当我驳斥将失去“XCopy”安装作为懒惰抱怨的论点时，我是否过于严厉？还是它变得有点“宗教”了，我应该选择看起来正确的东西？

感谢你帮助我看到光明。

丹

【问题讨论】：

根据 David 的回答，我得出的结论是，只要我们对所做的更改小心谨慎，GAC 就是存储我们的程序集的好地方。我认为在单个可识别位置的单个可安装实体将使我们的整体开发和部署策略更易于管理和维护。所以，再次感谢大卫的回应。尽管这显然是一个主观性的领域，但我已将其标记为答案。谢谢，丹

标签： .net deployment gac

【解决方案1】：

我使用以下弱策略。
使用 GAC - 当不同的程序使用共享程序集 + 版本控制时。
不要使用 GAC - 总是。

欢迎任何 cmets。

【讨论】：

【解决方案2】：

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

那么我的投票是什么？远离 GAC。让每个应用程序依赖于构建它们所依赖的程序集的版本。一个应用程序在该程序集中暴露的错误可能永远不会出现在其他应用程序中，因为它们以不同的方式使用程序集，所以让它们保持原样，您不必在每次共享 DLL 被修补时对 5 个不同的应用程序进行回归测试.

【讨论】：

是的，磁盘空间不是我真正关心的问题 :) 我很欣赏你的诚实回答，但我不得不争辩说，如果共享代码的两个消费者表现出不同但正确的行为，那么关于分离就有一个问号的功能。我想我反过来看事情——如果我让自己成为一个更好的程序员，那么 QED，我会写出更好的程序。
我会说肯定有一个平衡，但是。是的，你想成为一个更好的程序员，成为一个更好的程序员可以帮助你编写更好的程序，但是有更好的方法来成为一个更好的程序员，而不是在生产中通过压力烹饪程序集。
我不确定我是否理解您的“压力烹饪”术语。我完全同意采取平衡和务实的做法的必要性。问题在于，您和其他人对 GAC 问题的回答似乎可以被解释为“我们认为 GAC 是一个好主意，但我们希望避免让我们的代码愉快地工作的开销。”在这样的一揽子反应中呈现出一种相当有偏见的发展观点。我宁愿知道具体的风险并自己决定。如果我错了，请纠正我。
不，我完全支持你。我在这里看到的主要风险是我在原始帖子中提到的。如果您确实必须在 GAC 安装的程序集中更改某些内容，则必然需要对使用该特定程序集的每个应用程序进行回归测试。这可能会很糟糕。当然，我认为拥有多个版本的程序集也会变得令人讨厌，但在大多数情况下，我的应用程序一旦部署，几乎就在那里。我宁愿修复一个应用程序的错误，不理会正在运行的应用程序，也不愿冒险在尝试解决另一个应用程序时引入新错误。
感谢您的耐心等待大卫。谢谢你的回答。我完全理解并同意。那么，我们需要解决的问题是自动化和可靠的回归测试。我想这应该是一个新问题“我们认为门控签入+自动构建+单元测试能够提供这一层吗？”我松了一口气，除了我以外的每个人都看不到一些潜伏的讨厌:)