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

Question

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

Answer 1

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

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

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

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

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

Answer 2

如果您要交付一个由多个程序集组成的可重用库，但其中只有少数几个程序集构成一个外观，那么您可以考虑将这些程序集安装到 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 文件夹中，以便在运行时可用。
• 您可以安装 VS.NET 项目模板已经包含这 6 个引用。有点复杂，因为您应该在 安装之前将程序集的实际路径注入到此模板中。这只能由安装程序完成，因为此路径取决于安装路径。
• 您可以要求开发人员在 .csproj / .vbproj 文件中创建一个特殊的构建后步骤，将必要的依赖项复制到 Bin 文件夹。同样的缺点。
• 最后，您可以将所有程序集安装到 GAC 中。在这种情况下，开发人员必须从他们的项目中添加对 MyProduct.Facade.dll 的引用。无论如何，其他一切都将在运行时可用。

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

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

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

Answer 3

优势：

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

缺点：

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

建议：将 GAC 留给 MS 和朋友。技嘉现在很便宜。

Answer 4

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

因此，总而言之，从简单开始，如果您以后看到将您的程序集放入 GAC 和 NGEN 中获得显着的性能提升，那就去做吧，否则不要打扰。 GAC 更适用于希望库在更多应用程序之间共享的框架，在 99% 的情况下，您不需要它。

Answer 5

GAC 在完全信任的情况下运行，可供 Web 应用之外的应用程序使用。例如，Sharepoint 中的 Timer Jobs 必须在 GAC 中，因为 sptimer 服务是一个单独的进程。

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

Daniel Larson 有一个 post on CAS as well，其中详细说明了差异。

Answer 6

我认为使用 GAC 的最大优势之一是您可以注册同一个程序集的多个版本并可供您的应用程序使用。就个人而言，我不喜欢它如何限制从机器到机器的移动（我不想说，检查新 VPC 上的源代码并通过一系列步骤让它运行，因为我必须在其中注册东西GAC）

Answer 7

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