什么时候应该安装到 GAC 中，什么时候不应该安装？ （我实际上指的是在客户购买了我们的产品后安装在他们的机器上）。
-
我有一个程序集仅用于我的一个应用程序（GAC 或非 GAC）？
-
我有一个我的所有应用程序共享的程序集（GAC 或非 GAC）？
-
我的所有应用程序可能使用我的程序集的不同版本（GAC 或非GAC）？
这是三种情况......但我确信还有更多。 我不一定只寻找这三个问题的答案。
类似问题：有什么优点使用 GAC 的缺点和缺点？
When should you install into the GAC and when should you not? (I am referring, really, to installing on a client's machine when they have purchased our product(s)).
-
I have an assembly that is only going to be used with my one application (GAC or no-GAC)?
-
I have an assembly that all my applications share (GAC or no-GAC)?
-
All my applications may use different versions of my assembly (GAC or no-GAC)?
These are three scenarios... but I am sure there are more. I'm not necessarily looking an answer to only these three questions.
Similar question: What are the advantages and disadvantages of using the GAC?
发布评论
评论（7）
仅当同一服务器上的大量 Web 应用程序共享完全相同的库时，安装到 GAC 中才有意义。 例如，在 Sharepoint 服务器上，可能有数百个网站都需要共享相同的 Web 部件，因此在这种情况下，将编译的 Web 部件部署到 GAC 是有意义的。
It only makes sense to install into the GAC if lots and lots of web applications on the same server will be sharing exactly the same libraries. For example, on a Sharepoint server there can be hundreds of web sites that all need to share the same web part, so in this case it makes sense to deploy the compiled web part to the GAC.
一般 MS 指南
GAC 实际上是 Microsoft 通用 .NET 库的存储库。 是的，他们也让开发人员使用它，但根据经验，如果您不需要 GAC，就不要使用它。 如果没有坏处的话，让事情保持简单和本地化。
我只会出于性能原因考虑GAC，例如，如果您有一些巨大的程序集，请尝试将它们放入GAC中，并且NGEN 他们。 它应该会显着提高性能。 Microsoft 在安装过程中对所有标准 .NET 框架程序集执行此操作（现在您知道为什么安装需要这么长时间了）。 Paint.NET 也这样做（以缩短其应用程序的启动时间）。 然而，我们大多数人并不使用大型框架或 Photoshop 竞争对手，因此大多数时候，在 GAC 中进行组装所带来的性能提升微乎其微。 不值得放弃简单的 x-copy 部署。
一些开发人员可能会使用 GAC 来确保权限不足的用户无法删除或修改其程序集。
一些开发人员可能会使用 GAC 来确保权限不足的用户无法
对于其他人来说，这可能是出于版本控制的原因，但在这里您应该真正重新考虑。 我不会重复已经说过的话，您可以在此处阅读原因。 对于其他人来说
并且不要忘记，一旦您想要部署到 GAC 中，您的安装程序将需要管理员权限，您几乎可以忘记单击一次部署等...
General MS guidelines
GAC is really a repository for Microsoft common .NET libraries. Yes, they let developers use it too, but as a rule of thumb, if you don't need GAC, don't use it. keep things simple and local if it doesn't hurt.
I would consider GAC only for performance reasons, for example if you have some huge assemblies, try to place them into GAC and NGEN them. It should significantly increase performance. Microsoft does it for all standard .NET framework assemblies during installation (now you know why that installation takes so long). Paint.NET does it as well (to improve startup time of their app). However most of us don't work on huge frameworks or photoshop competitors, so most of the time, performance gains from having assembly in GAC are minimal. Not worth giving up simple x-copy deployment.
Some developers might use GAC to make sure that users with insufficient privileges can't delete or modify their assemblies.
For others it might be for versioning reasons but here you should really reconsider. I'm not going to repeat what has been already said, you can read here why.
And don't forget that once you want to deploy into GAC, your installer will need administrator privileges, you can pretty much forget click-once deployment, etc...
GAC 的有用案例：
除此之外，我倾向于像躲避瘟疫一样避开 GAC。 通过 robocopy 等方式将必要的 dll 部署到您的应用程序中要容易得多； 这提供了隔离并且易于部署。
Useful cases for GAC:
Other than that, I tend to avoid the GAC like the plague. It is far easier to just deploy the necessary dlls with your app via
robocopyetc; this gives isolation and easy deployment.如果您正在安装 asp.net Web 应用程序，并且您是所有者并拥有对计算机的完全控制权，那么在某些情况下，将您计划共享的程序集放在其中可能是有意义的全局程序集缓存中的站点/Web 实例。
如果将程序集放入 GAC 中，则可以显着改善服务器上应用程序的初始加载时间和内存使用情况，这些服务器具有相同 ASP.NET 应用程序的多个实例。 至少我在我们的服务器上看到了这一点，有数十个安装。
If you are installing asp.net web applications and you are the owner and have complete control over the machine, then in some cases it could make sense putting your assemblies, which you plan to share across sites/web instances in the global assembly cache.
You could dramatically improve the initial loading time and memory usage of the application on servers which have many multiple instances of the same ASP.NET applications if you put the assemblies in the GAC. At least I saw this on our servers with dozens of installations.
如果您要交付由多个程序集组成的可重用库，但只有少数程序集形成外观，并且该程序包已安装到开发人员的 PC 上，则可以考虑将程序集安装到 GAC 中。
想象一下，您运送了 6 个程序集，而这 6 个程序集中只有一个包含外观 - 即其他 5 个程序集仅由外观本身使用。 您交付：
使用您的项目的开发人员只想引用MyProduct.Facade.dll 在他们自己的项目中。 但是当他们的项目运行时，它必须能够递归地加载它引用的所有程序集。 如何实现这一目标？ 一般来说，它们必须在 Bin 文件夹中或 GAC 中可用：
注意：最后一个选项并不要求您在将项目传送到生产 PC 时执行相同的操作。 您可以将所有程序集发送到 Bin 文件夹中，也可以将它们安装到 GAC 中 - 一切都取决于您的意愿。
因此，所描述的解决方案显示了在开发过程中将第三方程序集放入 GAC 中的优势。 与生产无关。
您可能会发现，安装到 GAC 主要是为了解决所需程序集（依赖项）的位置问题。 如果程序集安装到 GAC 中，您可能会认为它存在于任何应用程序“附近”。 这就像将 .exe 的路径添加到 PATH 变量中，但是是以“托管方式”。 - 当然，这是相当简化的描述；）
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.
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:
Developers using your project would like to reference just MyProduct.Facade.dll in 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:
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.
So the solution described shows the advantage of putting third-party assemblies into GAC during the development. It doesn't related to production.
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 ;)
以下是 Chris Sells 提供的名为“避免 GAC”的链接
https://sellsbrothers.com/12503
解释是相当长，但简而言之，他确定的两种情况是
在不触及受影响的应用程序的情况下修复严重错误（并且不会破坏任何内容！）
在运行时在单独部署的程序集之间共享类型
注意：有一个很长的讨论线程在 Chris 帖子的末尾，非常好的评论列表。
Here's the link from Chris Sells called "Avoid the GAC"
https://sellsbrothers.com/12503
The explanation is pretty long, but in short, the two cases he identifies are
Fixing critical bugs without touching the affected apps (and without breaking anything!)
Sharing types at run-time between assemblies deployed separately
Note: There is a very long discussion thread at the end of Chris's the post, very nice list of comments.
首先，如果您要在客户端计算机上安装此应用程序，则需要添加一个自定义操作以在 GAC 中安装该应用程序，并在删除时添加另一个自定义操作。
在情况 A 上绝对不是 GAC
在情况 B 上如果您的库会不断更改，您将需要每次都将程序集的每个版本添加到 gac 中，并更新该程序集
在情况 C 上并行执行允许您运行不同的程序集版本并且您不需要添加任何内容来区分版本。
仅在您确实需要时使用
first if you are installing this on a client machine you will need to add a custom action to install the app in the GAC and another one when removing.
on case A definitely not GAC
on case B if your library will be constantly changing you will need to add every version of the assembly into the gac everytime and update to that assembly occurs
on case C side by side execution allows you to run different assembly versions and you dont need to add anything to differentiate the versions.
Used only if you really need to