当我部署我的程序集到GAC？ [英] When should I deploy my assemblies into the GAC?

问题描述

我想知道几乎什么样的大会，我应该部署GAC。

I would like to know practically what kind of Assemblies should I deploy in GAC.

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

Case 1: If in my Solution multiple project uses log4net.dll then should it be deployed in GAC?

案例2 ：如果我有多个应用程序部署在一台机器每使用log4net.dll这足以部署log4net.dll到GAC的原因

Case 2: If I have multiple application deployed in a machine each using log4net.dll is this the reason enough to deploy log4net.dll into GAC?

推荐答案

问：什么时候我应该部署我的程序集到GAC

Question: When should I deploy my assemblies into the GAC?

答：永远不要

实际，说实话，真正的答案：未落

Actual, honest, Real Answer: Hardly Ever

讨论

才会掉落的东西到GAC时，机器上的多个应用程序将使用的组件，当组装基础（可能被多个应用程序），当它被签署，而当你期望几乎从不更新部件。也许加入到了，有部署的每个应用程序的DLL多个独立的版本时，实际上是有害的。

Only drop things into the GAC when multiple apps on the machine will use the assembly, and when the assembly is foundational (likely to be used by multiple apps), when it is signed, and when you expect to almost never update that assembly. Maybe add into that, when having multiple independent versions of a DLL deployed with each application would actually be harmful.

后者的一个例子：假设你有2个独立的应用程序，自主研发并独立部署。然而，有一个possibbility，他们将-通信间。他们将交换......什么......在.NET Remoting的本地计算机上。如果你有在GAC单个组件，这些应用程序可以放心，互联互通将只是工作。然而，如果它们各自具有的组件的一个单独的版本，他们可能不能够交换的对象。 这是这样一个罕见的发生，你可能不需要它。如果你不知道，那么你就不需要它。

An example of the latter is: suppose you have 2 independent applications, independently developed and independently deployed. Nevertheless, there is a possibbility that they will inter-communicate. They will exchange ... something... over .NET Remoting on the local machine. If you have a single assembly in the GAC, these apps are assured that the inter-communication will just work. If, however, they each have a separate version of an assembly, they may not be able to exchange objects. This is such a rare occurrence that you probably don't need it. If you're not sure, then you don't need it.

该基地GAC场景是.NET基础类库。这些组件是由微软发布。他们是权威的。他们是基础。并签字。他们很少改变。所有的应用程序应该使用这些DLL的相同的副本。因此，他们属于在GAC。

The base GAC scenario is the .NET Base Class Library. These assemblies are shipped by Microsoft. They are authoritative. They are foundational. and signed. They rarely change. All apps should use the same copies of those DLLs. Therefore, they belong in the GAC.

在此相反，的您的应用程序的DLL不是来自微软，它们不是基础，而且很可能没有签署。他们改变次数多了，只有几个应用程序（也许只有一个！）使用每个DLL。没有GAC。

In contrast, your application DLLs are not from Microsoft, they are not foundational, and probably not signed. They change more often, and there are only few apps (maybe only one!) that use each DLL. No GAC.

我能想象一个硬件设备，比方说，一台数码相机，能安装.NET程序集，允许编程。这是一种情况，大会可以很好地成为GAC。它允许任意的.NET应用程序以编程方式访问数码相机。

I could imagine a hardware device, let's say a digital camera, that installs a .NET assembly to allow programmability. That's a scenario where the assembly might fit well into the GAC. It allows arbitrary .NET apps to access the digital camera programmatically.

您log4net的例子并不在我看来，足以证明将装配在GAC。想象其中的应用程序的一个得到的更新，并作为更新的一部分，它使用log4net的一个新版本的方案。怎么办？应的新的log4net组件被放置到GAC？可能不会。

Your log4net example is not, in my opinion, enough to justify putting the assembly in the GAC. Imagine the scenario where one of the apps gets an update, and as part of the update it uses a new version of log4net. Now what? Should the new log4net assembly be placed into the GAC? Probably not.

在整个应用程序是植根于premise内存和磁盘存储共享DLL的总体思路是稀缺的。曾几何时，这是真的。这是不正确的，任何更长的时间。如果有疑问，请不要使用GAC。

The whole idea of sharing DLLs across applications was rooted in the premise that memory and disk storage was scarce. Once upon a time, that was true. It is not true, any longer. When in doubt, don't use the GAC.

这篇关于当我部署我的程序集到GAC？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！