我们一般都知道,.NET Framework的GAC（global assembly cache)其实就是一个特殊的目录，如下图所示
但是它内部到底是什么结构呢？
很奇怪对吧？两个图完全不一样。不要惊讶，其实第一个图只是一个特殊的呈现方式。GAC里面确实就只有几个目录而已 。
一个比较完整的.NET Framework 2.0的GAC下子目录的结构如下所示：
- GAC
- GAC_32
- GAC_MSIL
- GAC_64
- NativeImages1_v1.1.4322
- NativeImages_v2.0.50727_32
- NativeImages_v2.0.50727_64
其中：
GAC是用于存放基于.NET Framework 1.0/1.1创建的Assemblies，这些Assemblies只能运行在32-bit 地址空间。
GAC_MSIL用于存放基于.NET Framework 2.0上的无特定CPU指定的Assemblies，这些assemblies可以运行在32-bit地址空间或者64-bit地址空间。
GAC_32也是用于存放基于.NET Framework 2.0创建的基于x86架构的Assemblies，因为这些Assemblies可以拥有32-bit的native CPU代码，所以只能运行在32-bit空间，可以直接在32-bit系统上运行或者使用WOW64技术在64-bit的OS系统上运行。
GAC_64用于存放.NET Framework 2.0上创建的基于x64或者IA64的Assemblies，这些Assemblies可能含有x64或者IA64的Native Code，所以他们只能运行在64-bit地址空间上。这个目录在32-bit的OS上不存在。值得注意的是，GAC_64中的Assemblies是根据系统架构决定，在x64系统上，该目录中的Assemblies就必须是基于x64的，IA64的Assemblies无法被装入，反之亦然。
以NativeImages开头的目录存放的通过NGen.exe编译assembly生成的基于当前平台的非managed代码，这个目录不需要Strongly named Assemblies，后面的数字对应了版本号。而基于.NET Framework 2.0的两个NativeImages目录名称最后的两个字符’64’和’ 32’则代表了对应的平台。
那么，如果我们往里面去查看呢？会发现什么呢？
也就是说，在某个目录中（以GAC_MSIL为例），又按照程序集名称分了目录，例如System是一个程序集名称。它就有一个目录。
那么，它是怎么区分版本的呢？其实很简单，在程序集内部又按照版本号和公钥分了子目录。然后才可以看到真正的dll
这样做的目的是什么呢？就是说，即便程序集名称和版本都一样，但是签名的密钥是不一样的话，他们仍然是可以区分的。要知道，程序集名称和版本号完全可以设置成一样的，但密钥是不可能模拟出来的。
最后，我们需要谈一个话题，就是CLR在查找程序集时的行为模式？意思就是说，如果一个程序集，它需要引用另外一个程序集，那么CLR到底是怎么查找的
好吧，有朋友可能会问：等等，CLR是怎么知道一个程序集需要引用另外的程序集呢？
Good question! 其实这是必须的. 一个程序集不光包含代码,还包含了其他一些东西,例如程序集元数据, 类型元数据,以及资源等等.
从下面的图形可以看到一个MANIFEST，它里面就有有关引用的信息
查看MAINFEST，我想你就明白了吧 。看下图的assembly extern mscorlib。这说明什么呢？意思就是说目前的这个程序集需要用到mscorlib，而且版本和公钥是什么
Ok，那么如果知道了这些信息，CLR是怎么找到mscorlib的呢？它一般情况下是遵循下面的关系
1. 程序集的根目录
2. GAC（应该是先找平台相关的目录，例如GAC_32,GAC_64，然后找GAC_MSIL)
3.如果上面都找不到，则继续查找当前程序是否设置了特殊的私有路径。这个在下面这个博客中我介绍过
http://www.cnblogs.com/chenxizhang/archive/2010/03/14/1685665.html
如果以上都找不到，就报告一个错误，失败了
以上的过程是发生在运行期间的。
那么在编译的时候，又是怎么样的呢？
1. 程序集的根目录
2. CSC程序的目录
3. GAC