我应该何时将我的程序集部署到GAC中？

Question

我想知道我应该在GAC中部署哪种程序集.

案例1:如果在我的解决方案中多个项目使用log4net.dll,那么它应该部署在GAC中吗？

案例2:如果我在一台机器中部署了多个应用程序,每个使用log4net.dll,这是将log4net.dll部署到GAC的原因吗？

Answer 1

问题:我应该何时将我的程序集部署到GAC中？

答: 永远不会

实际,诚实,真实答案: 几乎没有

讨论

当机器上的多个应用程序将使用程序集时,以及当程序集基础(可能由多个应用程序使用),签名时以及当您希望几乎从不更新该程序集时,只需将内容放入GAC.也许添加到那个,当每个应用程序部署多个独立版本的DLL实际上是有害的.

后者的一个例子是:假设您有2个独立的应用程序,独立开发和独立部署.然而,他们有可能相互交流.他们将在本地机器上通过.NET Remoting交换......某些东西.如果您在GAC中只有一个程序集,那么这些应用程序可确保相互通信正常工作.但是,如果它们各自具有单独版本的程序集,则它们可能无法交换对象. 这种情况非常罕见,您可能不需要它.如果你不确定,那么你不需要它.

基本GAC方案是.NET基类库.这些程序集由Microsoft提供.他们是权威的.它们是基础的.并签字.他们很少改变.所有应用程序都应使用这些DLL的相同副本.因此,它们属于GAC.

相反,您的应用程序DLL不是来自Microsoft,它们不是基础的,可能没有签名.它们更频繁地更改,并且只有少数应用程序(可能只有一个!)使用每个DLL.没有GAC.

我可以想象一个硬件设备,比如一个数码相机,安装.NET程序集以实现可编程性.这种情况下程序集可能很适合GAC.它允许任意.NET应用程序以编程方式访问数码相机.

在我看来,你的log4net示例不足以证明将程序集放入GAC.想象一下其中一个应用程序获得更新的情况,作为更新的一部分,它使用新版本的log4net.怎么办？是否应将新的log4net程序集放入GAC？可能不是.

跨应用程序共享DLL的整个想法植根于内存和磁盘存储稀缺的前提.曾几何时,这是真的.不再是真的了.如有疑问,请勿使用GAC.

Answer 2

log4net.dll的大小为95KB.即使你将它部​​署了100次,对于今天的硬盘来说也没那么重要.我尽可能避免使用GAC,原因如下:

• 它使部署更加困难,您必须告诉安装程序将哪些内容放入GAC.我喜欢创建简单的xcopy设置的可能性(复制dir进行安装,删除它以进行卸载).因为这很简单 - 但是只要你把事情放到GAC中,它就不会那么好用.
• 你必须签署你的集会.只是让他们进入GAC ....
• 一旦开发人员在他的visual studio项目中引用了GAC的内容,当另一位开发人员在他的电脑上打开解决方案时,该引用将会丢失.在成功打开并编译解决方案之前,他首先必须将所需的程序集放入GAC.那是一个真正的PITA.我希望能够检查,编译和运行没有错误.

Answer 3

您应该考虑加入GAC的唯一装配是成熟且稳定的装配.对于log4net,如果您对您拥有的版本稳定,成熟并且您不太可能很快更改该版本感到高兴,请随时将其置于GAC中.

不要试图在GAC中放置可能会发生变化的库,特别是如果您在内部开发它们,并且仍有进一步改进的余地.而是将它们部署为私有程序集.

我见过人们传播共享代码的奇迹.他们说"啊,我们将通过此代码更改同时改进20个应用程序".问题是,如果你弄错了,你也可以同时破坏20个应用程序.我见过有人说"我刚刚推出了X网站.你能检查网站AW以确保它们仍能正常工作吗？".

私有程序集可能很麻烦,但您可能遇到的问题仅限于部署它们的特定应用程序.如果您不是100%确定程序集不稳定且成熟,请不要将其放入GAC中.

相信我,你会睡得更好.

Answer 4

您所描述的是将程序集放入GAC的足够好的情况.说实话,我会避免它.使用GAC,您必须担心强大的命名和信任程序集以及特定的程序集版本控制.如果您没有明确的理由需要这些.为每个项目多次部署dll同样容易.

我知道这不利于存储同一段代码等的多个副本,但我总是发现避免使用GAC更容易.当我使用它时,GAC一直很麻烦,因为你必须担心GAC是否具有项目的所有正确程序集(因为程序集可以引用其他程序集).当你不使用GAC时,它会容易得多,"组件是否存在？" "是的,他们在应用程序文件夹中."

我发现它有用的唯一一次是我必须构建SharePoint Services WSS 2.0.我遇到了更新配置部分以允许信任很麻烦(因为公司策略)并将其置于GAC中以使其完全受信任的时间.这是一个非常罕见的案例.