.net 使用 GAC 的优点和缺点是什么?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/23578/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What are the advantages and disadvantages of using the GAC?
提问by FantaMango77
And on top of that, are there cases where one has to use the global assembly cache or where one cannot use it?
最重要的是,是否存在必须使用全局程序集缓存或不能使用它的情况?
回答by lubos hasko
- Loading assemblies from GAC mean less overhead and security that your application will always load correct version of .NET library
- You shouldn't ngen assemblies that are outside of GAC, because there will be almost no performance gain, in many cases even loss in performance.
- You're already using GAC, because all standard .NET assemblies are actually in GAC and ngened (during installation).
- Using GAC for your own libraries adds complexity into deployment, I would try to avoid it at all costs.
- Your users need to be logged as administrators during installation if you want to put something into GAC, quite a problem for many types of applications.
- 从 GAC 加载程序集意味着更少的开销和安全性,您的应用程序将始终加载正确版本的 .NET 库
- 您不应该生成 GAC 之外的程序集,因为几乎不会有性能提升,在许多情况下甚至会降低性能。
- 您已经在使用 GAC,因为所有标准的 .NET 程序集实际上都在 GAC 中并已生成(在安装期间)。
- 将 GAC 用于您自己的库会增加部署的复杂性,我会不惜一切代价尝试避免它。
- 如果您想将某些内容放入 GAC,您的用户需要在安装期间以管理员身份登录,这对于许多类型的应用程序来说都是一个问题。
So to sum it all, start simple and if you later see major performance gains if you put your assemblies into GAC and NGEN them, go for it, otherwise don't bother. GAC is more suitable for frameworks where there is expectation for library to be shared among more applications, in 99% of cases, you don't need it.
因此,总而言之,从简单开始,如果以后将程序集放入 GAC 和 NGEN 中,如果您看到显着的性能提升,那就去做吧,否则不要打扰。GAC 更适合那些期望在更多应用程序之间共享库的框架,在 99% 的情况下,您不需要它。
回答by Eduardo Molteni
Advantage:
优势:
- Only one place to update your assemblys
- You use a little less hard drive space
- 只有一处可以更新您的程序集
- 你使用更少的硬盘空间
Disadvantage:
坏处:
- If you need to update only one website, you can't. You may end with the other websites in the webserver broken
- 如果您只需要更新一个网站,则不能。您可能会以网络服务器中的其他网站损坏而告终
Recommendation: Leave the GAC to MS and friends. The gigabyte is very cheap now.
建议:将 GAC 留给 MS 和朋友。技嘉现在很便宜。
回答by Kev
The GAC can also be used by assemblies that require elevated permissions to perform privileged operations on behalf of less trusted code (e.g. a partial trust ASP.NET application).
GAC 也可由需要提升权限以代表不太受信任的代码(例如,部分信任的 ASP.NET 应用程序)执行特权操作的程序集使用。
For example, say you have a partial trust ASP.NET application which needs to perform a task that would require elevated privileges, i.e. Full Trust. The solution is to put the code that requires elevated privileges into a separate assembly. The assembly is marked with the AllowPartiallyTrustedCallersattribute and the class that contains the privileged logic is marked with the PermissionSet attribute, something like this:
例如,假设您有一个部分信任的 ASP.NET 应用程序,它需要执行一项需要提升权限的任务,即完全信任。解决方案是将需要提升权限的代码放入单独的程序集中。程序集用AllowPartiallyTrustedCallers属性标记,包含特权逻辑的类用 PermissionSet 属性标记,如下所示:
[PermissionSet(SecurityAction.Assert, Unrestricted=true)]
Our assembly would be given a strong name (signed) and then deployed into the GAC.
我们的程序集将被赋予一个强名称(签名),然后部署到 GAC 中。
Now our partially trusted app(s) can utilise the trusted assembly in the GAC to carry out a specific and narrow set of privileged operations without losing the benefits of partial trust.
现在,我们的部分受信任应用程序可以利用 GAC 中的受信任程序集来执行一组特定且范围狭窄的特权操作,而不会失去部分信任的好处。
回答by Alex Yakunin
If you're shipping a reusable library consisting of multiple assemblies, but only few of them form a facade, you can consider installing the assemblies into GAC, if the package is installed to developer's PCs.
如果您要交付一个由多个程序集组成的可重用库,但其中只有少数几个构成了外观,那么您可以考虑将这些程序集安装到 GAC 中,前提是该程序包已安装到开发人员的 PC 上。
Imagine, you ship 6 assemblies, and only one of these 6 assemblies contains a facade - i.e. other 5 are used only by the facade itself. You ship:
想象一下,您运送了 6 个程序集,而这 6 个程序集中只有一个包含一个门面——即其他 5 个仅由门面本身使用。您运送:
- MyProduct.Facade.dll- that's the only component intended to be used by developers
- MyProduct.Core.dll - used by MyProduct.Facade.dll, but not intended to be used by developers
- MyProduct.Component1.dll - the same
- MyProduct.Component2.dll - the same
- ThirdParty.Lib1.dll - third-party library used by MyProduct.Component1.dll
- ThirdParty.Lib2.dll - the same
- etc.
- MyProduct.Facade.dll- 这是开发人员使用的唯一组件
- MyProduct.Core.dll - 由 MyProduct.Facade.dll 使用,但不打算供开发人员使用
- MyProduct.Component1.dll - 相同
- MyProduct.Component2.dll - 相同
- ThirdParty.Lib1.dll - MyProduct.Component1.dll 使用的第三方库
- ThirdParty.Lib2.dll - 相同
- 等等。
Developers using your project would like to reference just MyProduct.Facade.dllin their own projects. But when their project runs, it must be able to load all the assemblies it references - recursively. How this can be achieved? In general, they must be available either in Bin folder, on in GAC:
使用您的项目的开发人员只想在他们自己的项目中引用MyProduct.Facade.dll。但是当他们的项目运行时,它必须能够加载它引用的所有程序集 - 递归。如何实现?通常,它们必须在 Bin 文件夹或 GAC 中可用:
- You may ask the developers to locate your installation folder and add references to all Nassemblies you put there. This will ensure they'll be copied into Bin folder to be available in runtime.
- You may install VS.NET project template already containing these 6 references. A bit complex, since you should injectthe actual path to your assemblies into this template beforeits installation. This can be done only by installer, since this path depends on installation path.
- You may ask developers to create a special post-build step in .csproj / .vbproj filecopying the necessary dependencies to Bin folder. The same disadvantages.
- Finally, you may install all your assemblies into GAC. In this case developers must add the reference just to MyProduct.Facade.dll from their project. Everything else will be available in runtime anyway.
- 您可以要求开发人员找到您的安装文件夹并添加对您放置在那里的所有 N 个程序集的引用。这将确保它们将被复制到 Bin 文件夹中以在运行时可用。
- 您可以安装已经包含这 6 个参考的VS.NET 项目模板。有点复杂,因为您应该在安装之前将程序集的实际路径注入到该模板中。这只能由安装程序完成,因为此路径取决于安装路径。
- 您可以要求开发人员在 .csproj / .vbproj 文件中创建一个特殊的构建后步骤,将必要的依赖项复制到 Bin 文件夹。一样的缺点。
- 最后,您可以将所有程序集安装到 GAC 中。在这种情况下,开发人员必须从他们的项目中添加仅对 MyProduct.Facade.dll 的引用。无论如何,其他所有内容都将在运行时可用。
Note: last option doesn't make you to do the same while shipping the project to production PCs. You can either ship all the assemblies within Bin folder, or install them into GAC - all depends all your wish.
注意:最后一个选项不会让您在将项目运送到生产 PC 时做同样的事情。您可以在 Bin 文件夹中发送所有程序集,也可以将它们安装到 GAC 中 - 一切都取决于您的愿望。
So the solution described shows the advantage of putting third-party assemblies into GAC during the development. It doesn't related to production.
因此,所描述的解决方案显示了在开发过程中将第三方程序集放入 GAC 的优势。它与生产无关。
As you may find, installation into GAC is mainly intended to solve the problem of location of required assemblies (dependencies). If an assembly is installed into GAC, you may consider it exists "nearby" any application. It's like adding path to .exe to your PATH variable, but in "managed way".- of course, this is rather simplified description ;)
您可能会发现,安装到 GAC 主要是为了解决所需程序集(依赖项)的位置问题。如果一个程序集安装到 GAC 中,您可能会认为它存在于任何应用程序“附近”。这就像将 .exe 的路径添加到您的 PATH 变量中,但是以“托管方式”。- 当然,这是相当简化的描述;)
回答by Michael Stum
The GAC runs with Full Trust and can be used by applications outside of your Web App. For example, Timer Jobs in Sharepoint HAVE to be in the GAC because the sptimer service is a separate process.
GAC 以完全信任的方式运行,可供 Web 应用程序之外的应用程序使用。例如,Sharepoint 中的计时器作业必须在 GAC 中,因为 sptimer 服务是一个单独的进程。
The "Full Trust" Part is also a possible source for security issues. Sure, you can work with Code Access Security, but I do not see too many Assemblies using CAS unfortunately :( The /bin Folder can be locked down to Medium which is normally fine.
“完全信任”部分也是安全问题的可能来源。当然,您可以使用代码访问安全性,但不幸的是,我没有看到太多使用 CAS 的程序集:( 可以将 /bin 文件夹锁定为 Medium,这通常很好。
Daniel Larson has a post on CAS as wellwhich details the differences a bit more.
回答by jonezy
I think one of the biggest advantages of using the GAC is that you can have multiple versions of the same assembly registered and available to your applications. Personally, i don't like how it restricts movement from machine to machine (i don't like having to say, check out source on a new VPC and go through a bunch of steps to get it running because I have to register stuff in the GAC)
我认为使用 GAC 的最大优势之一是您可以注册同一个程序集的多个版本并可供您的应用程序使用。就我个人而言,我不喜欢它如何限制机器之间的移动(我不想说,查看新 VPC 上的源代码并通过一系列步骤使其运行,因为我必须在海关总署)
回答by Vaibhav
In all my life, I have had maybe one application where I had to put an assembly in the GAC, simply because these assemblies were part of a framework that a number of applications would use it, and it seemed right to put them into the GAC.
在我的一生中,我可能有过一个应用程序,我不得不将一个程序集放在 GAC 中,仅仅因为这些程序集是许多应用程序会使用它的框架的一部分,而将它们放入 GAC 似乎是正确的.

