我知道这个问题来来回回,但我似乎找不到一个令人满意的答案。
程序集应该放在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支持并排安装不同版本的“相同”程序集?
让我把我的担忧具体化。我们有越来越多的web应用程序套件(到目前为止有5个)。它们的核心是通过API调用和数据库扩展对第三方应用程序的扩展。显然,因此,所有这些应用程序都共享大量公共代码,我们正在开发一组新的核心共享库,以提高我们的质量和可维护性等。
当然,我希望这个共享功能只需安装一次即可共享。所有关于开启维护噩梦的争论似乎都是基于一些纪律不佳的世界。如果你破坏了ABI,那么颠簸AssemblyVersion就足以让你现有的应用程序正常工作。
广交会真的是毫无戒心的人的陷阱吗?我是不是太天真了?当我将“XCopy”安装丢失的争论斥为懒惰的抱怨时,我是不是不必要地苛刻?或者它变得有点“宗教”了,我应该只接受看起来正确的东西?
谢谢你帮我重见天日。
丹
发布于 2010-03-04 19:29:13
我个人从来没有在GAC中直接安装过任何程序集(除了纯粹的学术练习)。我以前听过关于从集中位置使用可从多个应用程序访问的程序集的争论,虽然这看起来有点吸引人,但就我个人而言,这不值得我花时间。现在的电脑都有320 of的硬盘空间……我微不足道的160K程序集不会对此产生任何影响,即使它被复制了5次。(当然,有些人可能会争论“公地问题”……你知道:“如果每个开发人员都这么想的话……”,但我离题了。我选择不这样做的主要原因是因为一个特定的应用程序可能以某种方式依赖于程序集,而另一个应用程序可能以另一种方式依赖于它。虽然在理想情况下,对此程序集的更新应该永远不会影响依赖它的应用程序,但在现实中,它经常会影响。如果我修复某个程序集的问题是因为某个特定的应用程序有问题,那么我会在不知不觉中影响依赖于该特定程序集的其他应用程序。另一方面,有些人可能会争辩说,这种情况会让我们成为更好的程序员,并让我们的GAC共享程序集更加防弹。这很棒,但我作为程序员的工作主要不是让自己成为一名更好的程序员,而是编写能够工作的程序,这样做,我就会成为一名更好的程序员。
我该投什么票?离GAC远点。让每个应用程序依赖于它们所依赖的程序集的版本。由一个应用程序在该程序集中暴露的bug可能永远不会出现在其他应用程序中,因为它们以不同的方式使用该程序集,所以让它们保持不变,这样您就不必在每次对共享DLL进行修补时都回归测试5个不同的应用程序。
发布于 2010-03-04 19:28:46
我使用下面的弱策略。
使用GAC -当不同的程序使用共享程序集+版本控制时。
不要使用GAC --总是这样。
欢迎提出任何意见。
https://stackoverflow.com/questions/2378791
复制相似问题