Dan*_*all 5 .net deployment gac
我知道这个问题一遍又一遍,但我似乎无法找到满意的答案.
组装是否应该进入GAC？这些问题:何时何时不安装到gac中以及使用GAC的优点和缺点是什么,准确地解决了这个问题,但答案非常多"建议......"或者"你应该只......".为什么？？？
很多GAC反对的博客似乎都是从5/6年前开始的,当时.Net的明星正在开始崛起.我们现在还在吗？当然,DLL-Hell已经成为过去,GAC支持并排安装不同版本的"相同"组件？
让我充实我的担忧.我们有越来越多的网络应用程序(到目前为止已有5个).它们的核心是通过API调用和数据库扩展对第三方应用程序的扩展.因此,显然,所有这些应用程序共享大量代码,我们正在开发一组新的核心共享库,以提高我们的质量,可维护性等.
当然,我希望这个共享功能安装一次并共享.所有关于打开维护噩梦的争论似乎都是基于一些不良纪律的世界.如果你打破了ABI,那么碰撞AssemblyVersion就足以让现有的应用程序保持正常运行.
对于不知情的人来说,GAC真的是一个蜜罐吗？我天真吗？当我驳斥"XCopy"安装失败的论点时,我是不是觉得不必要的苛刻？或者它是否有点"宗教",我应该选择看似正确的东西？
谢谢你帮我看清楚.
担
我个人从未直接在 GAC 中安装任何程序集（除非作为纯粹的学术练习）。我之前听过关于从多个应用程序访问的集中位置使用程序集的争论，虽然这似乎有点有吸引力，但就我个人而言，这不值得我花时间。如今，计算机配备了 320GB 的硬盘空间……即使复制了 5 次，我那区区 160K 的程序集也不会对此产生任何影响。（当然，有些人可能会争论“公共问题”......你知道：“如果每个开发人员都这么想......”，但我离题了）。我选择不这样做的主要原因是因为一个特定的应用程序可能以一种方式依赖于程序集，而另一个应用程序可能以另一种方式依赖于它。虽然在理想情况下，对此程序集的更新永远不会影响依赖它的应用程序，但实际上，它经常会影响。如果我因为特定应用程序存在问题而修复程序集问题，那么我会无意中影响依赖该特定程序集的其他应用程序。另一方面，有些人可能会争辩说，这种情况使我们成为更好的程序员，并使我们的 GAC 共享程序集更加防弹。这很好，但作为一名程序员，我的工作主要不是让自己成为一名更好的程序员，而是编写有效的程序，这样做，我将成为一名更好的程序员。
那么我的投票是什么？远离 GAC。让每个应用程序依赖于它们构建时所依赖的程序集的版本。一个应用程序在该程序集中暴露的错误可能永远不会出现在其他应用程序中，因为它们以不同的方式使用该程序集，因此不要管它们，每次修补共享 DLL 时，您都不必对 5 个不同的应用程序进行回归测试。