当大会将注册到GAC时，我应该如何在我的项目中引用我的大会
本文关键字：我的 引用 项目 注册 GAC 我应该 | 更新日期: 2023-09-27 17:50:20
我已经构建了一个。net程序集，并将其注册到GAC中
安装MSI安装程序后的"C:'Windows'Microsoft.NET'assembly'GAC_MSIL"。现在在我的开发计算机上，当我构建一个使用此程序集的项目时，我应该使用什么参考。我知道如果大会注册了，那么它优先，所以在我的开发机器上它没有注册。我使用一个简单的路径到程序集项目的BIN文件夹。
但我的问题是:当我的主要项目(引用这个.dll)部署，当然我使用的路径不再有效时，这会导致问题甚至减慢速度吗?
我知道在GAC中仍然可以找到Assembly，但是我很想知道这是否会导致问题。
GAC是一个部署细节。对于像微软这样的公司来说，这是件好事，这样他们就可以可靠地为。net框架程序集部署安全和维护更新，并确保程序集的某个文件夹中没有丢失的副本，他们永远找不到并更新。
在开发机器上自己使用GAC通常会导致崩溃。它只是方式太容易更新你的源代码，完全忘记更改[AssemblyVersion]或重新注册更新后的程序集。这会导致您的程序加载没有更改的陈旧DLL，您将浪费生命中的一个小时来弄清楚为什么更改似乎不起作用。
项目的参考程序集不应该是GAC中的程序集，而应该是您保存在某个地方的副本。要么通过构建项目生成(非常常见的情况)，要么签入到源代码控制中。就像。net引用程序集一样，它的副本位于c:'program files'reference assemblies.
即使在用户的机器上，在使用GAC时也应该三思而后行。DLL地狱一直是程序员应该担心的问题。如果你有两个程序，它们都在GAC中使用一个DLL，那么很容易为DLL部署bug修复，修复一个程序中的问题，但对另一个程序造成严重破坏。使用本地部署时不会出现的问题，将DLL的副本放入与EXE相同的目录中。
也许你有和微软一样的更新问题，GAC对于可靠地找到DLL是有用的。然而，这种情况并不常见。本地部署几乎总是您的首选。
无论你想要什么-这取决于你是否想要调试你的程序集。如果您不需要调试程序集，那么就从GAC加载它(毕竟，它是加载程序集时首先搜索的地方)。
在我看来，这不应该是个问题，也不应该导致任何性能问题。组装位置的确定是一个过程，国际海事组织不是那么昂贵，要考虑。
当使用第三方库开发软件时，您正在使用的组合实际上经常是这样的情况，例如，Microsoft Patterns and Practices library安装在开发机器的GAC中，并从GAC中引用和加载，但是在LIVE环境中，Lib-Assembly在应用程序的bin目录中交付。在我的工作中，这是开发和部署MVC应用程序的首选方式，因为这大大简化了部署过程。你可以看看这个SO的答案和这篇MSDN文章-运行时如何定位程序集。