使用 GAC 的优点和缺点是什么？

Question

除此之外，是否存在必须使用全局程序集缓存或不能使用它的情况？

Answer 1

优点：

• 只有一个地方可以更新程序集
• 您使用的硬盘空间稍微少一点

缺点：

• 如果您只需要更新一个网站，则不能。 您可能会因网络服务器中的其他网站损坏而结束

建议：将 GAC 留给 MS 和朋友。 现在千兆字节很便宜。

Answer 2

• 从 GAC 加载程序集意味着更少的开销和安全性，您的应用程序将始终加载正确版本的 .NET 库。
• 您不应该生成 GAC 外部的程序集，因为几乎不会有任何性能增益，在许多情况下甚至会损失性能。
• 您已经在使用 GAC，因为所有标准 .NET 程序集实际上都在 GAC 中并生成（在安装期间）。
• 对您自己的库使用 GAC 会增加部署的复杂性，我会不惜一切代价尝试避免它。
• 如果您想将某些内容放入 GAC 中，您的用户需要在安装过程中以管理员身份登录，这对于许多类型的应用程序来说都是一个问题。

总而言之，从简单开始，如果您稍后将程序集放入 GAC 和 NGEN 中看到性能大幅提升，那就继续吧，否则就不用费心了。 GAC更适合那些期望库在更多应用程序之间共享的框架，在99%的情况下，你不需要它。

Answer 3

在我的一生中，我可能有一个应用程序，我必须将程序集放入 GAC 中，仅仅是因为这些程序集是许多应用程序将使用它的框架的一部分，并且将它们放入 GAC 中似乎是正确的。

Answer 4

我认为使用 GAC 的最大优点之一是您可以注册同一程序集的多个版本并可供您的应用程序使用。 就我个人而言，我不喜欢它如何限制从一台机器到另一台机器的移动（我不喜欢不得不说，检查新 VPC 上的源代码并执行一系列步骤来让它运行，因为我必须在政府咨询委员会 (GAC)

Answer 5

如果您要交付由多个程序集组成的可重用库，但只有少数程序集形成外观，并且该程序包已安装到开发人员的 PC 上，则可以考虑将程序集安装到 GAC 中。

想象一下，您运送了 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 6

GAC 以完全信任方式运行，可供 Web 应用程序外部的应用程序使用。 例如，Sharepoint 中的计时器作业必须位于 GAC 中，因为 sptimer 服务是一个单独的进程。

“完全信任”部分也是安全问题的可能根源。 当然，您可以使用代码访问安全性，但不幸的是，我没有看到太多使用 CAS 的程序集 :( /bin 文件夹可以锁定到 Medium，这通常没问题。Daniel

Larson 有一个 也在 CAS 上发帖，其中详细介绍了差异。

Answer 7

需要提升权限才能代表不太受信任的代码（例如部分信任的 ASP.NET 应用程序）执行特权操作的程序集也可以使用 GAC。

例如，假设您有一个部分信任的 ASP.NET 应用程序，该应用程序需要执行需要提升权限的任务，即完全信任。 解决方案是将需要提升权限的代码放入单独的程序集中。 程序集用 AllowPartiallyTrustedCallers 属性标记，包含特权逻辑的类用 PermissionSet 属性标记，如下所示：

[PermissionSet(SecurityAction.Assert, Unrestricted=true)]

我们的程序集将被赋予一个强名称（签名），然后部署到广汽集团。

现在，我们部分受信任的应用程序可以利用 GAC 中的受信任程序集来执行一组特定且狭窄的特权操作，而不会失去部分信任的好处。