我应该什么时候将我的程序集部署到 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个独立的应用，独立开发和独立部署.尽管如此，它们仍有可能相互通信.他们将交换......东西......通过本地机器上的.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 基类库.这些程序集由 Microsoft 提供.他们是权威的.它们是基础.并签字.他们很少改变.所有应用程序都应使用这些 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 不是来自 Microsoft，它们不是基础的，并且可能没有签名.它们更频繁地更改，并且只有少数应用程序(可能只有一个！)使用每个 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.

跨应用程序共享 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屋！