何时何地 - 不安装到GAC？

Question

什么时候应该安装到GAC中，什么时候不应该安装？ （我指的是，当他们购买我们的产品时，在客户的机器上安装）。

1. 我的程序集只能用于我的一个应用程序（GAC或无GAC）？

2. 我有一个所有应用程序共享的程序集（GAC或无GAC）？

3. 我的所有应用程序可能使用我的程序集的不同版本（GAC或无GAC）？

这是三种情况......但我相信还有更多。我不一定只回答这三个问题。

类似的问题：What are the advantages and disadvantages of using the GAC?

Answer 1

一般MS指南

1. 没有
2. 没有
3. 没有

GAC实际上是Microsoft常见.NET库的存储库。是的，他们也允许开发人员使用它，但根据经验，如果您不需要GAC，请不要使用它。如果没有伤害，请保持简单和本地化。

• 我会考虑GAC仅出于性能原因，例如，如果您有一些巨大的程序集，请尝试将它们放入GAC并NGEN。它应该显着提高性能。 Microsoft在安装期间为所有标准.NET框架程序集执行此操作（现在您知道为什么安装需要这么长时间）。 Paint.NET也是这样做的（以改善他们的应用程序的启动时间）。但是，我们大多数人都没有在庞大的框架或photoshop竞争对手上工作，因此大多数时候，在GAC中进行组装所带来的性能提升很小。不值得放弃简单的x-copy部署。

• 某些开发人员可能会使用GAC来确保权限不足的用户无法删除或修改其程序集。

• 对于其他人来说，这可能是出于版本控制的原因，但在这里你应该重新考虑一下。我不打算重复已经说过的话，you can read here why。

不要忘记，一旦您想要部署到GAC，您的安装程序将需要管理员权限，您几乎可以忘记点击一次部署等...

Answer 2

GAC的有用案例：

• COM可调用代码 - 即您希望某些非.NET代码能够在不弄乱dll等的情况下访问您。
• Serviced Components（COM +）
• 如果您编写的代码非常常见，那么使用GAC实际上是有意义的 - 主要是.NET框架组件等
• 如果您想使用NGEN预先JIT代码

除此之外，我倾向于像瘟疫那样避开GAC。通过robocopy等方式使用您的应用程序部署必要的dll要容易得多;这使得隔离和易于部署。

Answer 3

如果您正在安装 asp.net Web应用程序并且您是所有者并且可以完全控制该计算机，那么在某些情况下，放置您计划在全局程序集缓存中跨站点/ Web实例共享。

如果将程序集放在GAC中，则可以显着改善具有相同ASP.NET应用程序的多个实例的服务器上的应用程序的初始加载时间和内存使用量。至少我在我们的服务器上看到了这几个安装。

Answer 4

如果您要发布包含多个程序集的可重用库，但只有少数几个构成外观，则可以考虑将程序集安装到GAC中（如果程序包已安装到开发人员的PC中）。

想象一下，您运送6个装配体，这6个装配体中只有一个包含立面 - 即其他5个仅由立面本身使用。你发货：

• MyProduct.Facade.dll - 这是开发人员唯一可以使用的组件
• MyProduct.Core.dll - 由MyProduct.Facade.dll使用，但不打算供开发人员使用
• MyProduct.Component1.dll - 相同
• MyProduct.Component2.dll - 相同
• ThirdParty.Lib1.dll - MyProduct.Component1.dll使用的第三方库
• ThirdParty.Lib2.dll - 相同
• 等

使用您的项目的开发人员希望在他们自己的项目中引用 MyProduct.Facade.dll 。但是当他们的项目运行时，它必须能够加载它所引用的所有程序集 - 递归。如何实现这一目标？通常，它们必须在Bin文件夹中，在GAC中可用：

• 您可以要求开发人员找到您的安装文件夹，并添加对您放置的所有N 程序集的引用。这将确保它们将被复制到Bin文件夹中以便在运行时可用。
• 您可以安装已包含这6个引用的VS.NET项目模板 。有点复杂，因为在安装之前，将注入程序集的实际路径。这只能由安装程序完成，因为此路径取决于安装路径。
• 您可以要求开发人员在.csproj / .vbproj文件中创建一个特殊的后期构建步骤，将必要的依赖项复制到Bin文件夹。同样的缺点。
• 最后，您可以将所有程序集安装到GAC 。在这种情况下，开发人员必须从他们的项目中添加对MyProduct.Facade.dll的引用。无论如何，其他所有东西都将在运行时可用。

注意：在将项目运送到生产PC时，最后一个选项不会让您这样做。您可以在Bin文件夹中发送所有程序集，也可以将它们安装到GAC中 - 所有这些都取决于您的所有愿望。

因此，所描述的解决方案显示了在开发过程中将第三方程序集放入GAC的优势。它与生产无关。

您可能会发现，安装到GAC主要是为了解决所需程序集（依赖项）的位置问题。如果将程序集安装到GAC中，您可能会认为它存在于任何应用程序“附近”。这就像将.exe的路径添加到PATH变量，但是以“托管方式”。 - 当然，这是相当简化的描述;）

Answer 5

以下是来自Chris Sells的名为“避免GAC”的链接

https://sellsbrothers.com/12503

解释很长，但简而言之，他确定的两个案例是

1. 修复关键错误而不触及受影响的应用程序（并且不会破坏任何内容！）

2. 在单独部署的程序集之间的运行时共享类型

注意：有一个很长的讨论话题at the end of Chris's the post，非常好的评论列表。

Answer 6

首先，如果要在客户端计算机上安装此程序，则需要添加自定义操作以在GAC中安装应用程序，并在删除时添加另一个应用程序。

案例A肯定不是GAC

在案例B上如果你的库会不断变化，你需要每次都将每个版本的程序集添加到gac中并更新到该程序集

在案例C上并排执行允许您运行不同的程序集版本，并且您不需要添加任何内容来区分版本。

仅在您确实需要

时使用

Answer 7

如果同一服务器上的大量Web应用程序将共享完全相同的库，那么安装到GAC中才有意义。例如，在Sharepoint服务器上，可能有数百个网站都需要共享同一个Web部件，因此在这种情况下，将已编译的Web部件部署到GAC是有意义的。