当我将位于GAC (%SystemRoot% assembly)中的引用添加到我的项目和不位于GAC中的程序集时（从部署的角度来看）会发生什么？我的意思是从部署的角度向项目添加SHARED引用和Private引用之间的区别？
我们通常不使用GAC，更喜欢将所有依赖项隐藏在%installdir%文件夹本身中。我想这就是你所说的私有引用，而不是GAC安装的共享引用。以下是我的原因。
-
GAC要求对程序集进行版本控制和强命名。虽然dot-net确实提供了一些优秀的版本控制手段，但它也确实让（noob）程序员感到困惑。以下是程序集版本、文件版本、应用程序版本的全部负担，以及了解程序集中的哪种更改会影响这些版本中的哪一个。此外，GAC和强名称只会影响程序集版本。
-
版本控制会影响修补。对于GACed dll，patchig即使不是不可能，也是有问题的。
-
安装到GAC需要管理员权限。如果你的目标受众中有很大一部分是企业用户，而你的应用程序更像是试用版，那么这将是一个巨大的问题。
-
依赖GAC的应用程序不可xcopy分发。它必须由安装程序正确安装。例如，我的应用程序带有一个命令行实用程序。像这样的东西通常不应该安装。人们期望exe在计算机之间复制/粘贴。我所需要做的就是让他们复制整个文件夹。
因此，从部署的角度来看，广汽并没有那么有利。由于它的存在，它确实带来了一些性能优势，但只有当性能瓶颈是CPU时，这一点才会显现出来。我的应用程序在网络和数据库上有性能瓶颈，所以本机代码没有帮助。不过，这可能不是你的情况，所以要评估你的选择。
另一件事是，不使用GAC也没有坏处。我在一个安装程序中捆绑了四个应用程序。用户勾选要安装的。所有DLL都有90%的通用DLL。安装后，这90个dll在所有应用程序文件夹（程序文件\myapp1、myapp2）中都会重复，但安装程序足够智能，只能携带所有dll的一个副本。因此安装程序的大小不会增加。安装的大小增加了，但这在当今的Tera字节磁盘中并不重要。没有人关注应用程序的安装大小。所有人都关心的是安装程序下载所需的时间。GAC对此没有帮助。
当然，框架DLL，那些自带dot-net框架的DLL，最好从GAC中使用，而不是随身携带。