通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（五）代码片段

CodeSnippet.Cn
代码片段

通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（五）

Csharp 小笨蛋发布于：2021年03月22日更新于：2021年03月05日 139

**[通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（一）](https://www.codesnippet.cn/home/list/16 "通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（一）")**
**[通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（二）](https://www.codesnippet.cn/home/list/17 "通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（二）")**
**[通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（三）](https://www.codesnippet.cn/home/list/18 "通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（三）")**
**[通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（四）](https://www.codesnippet.cn/home/list/19 "通俗易懂，什么是.NET?什么是.NET Framework？什么是.NET Core？（四）")**

### 程序集的规则
上文我通过ILDASM来描述CLR执行代码的方式，但还不够具体，还需要补充的是对于程序集的搜索方式。

对于System.Environment类型，它存在于mscorlib.dll程序集中，demo.exe是个独立的个体，它通过csc编译的时候只是注册了引用mscorlib.dll中的类型的引用信息，并没有记录mscorlib.dll在磁盘上的位置，那么，CLR怎么知道get_CurrentDirectory的代码？它是从何处读取mscorlib.dll的？
对于这个问题，.NET有个专门的概念定义，我们称为 程序集的加载方式。

#### 程序集的加载方式
上文我通过ILDASM来描述CLR执行代码的方式，但还不够具体，还需要补充的是对于程序集的搜索方式。

#### 程序集的加载方式
对于自身程序集内定义的类型，我们可以直接从自身程序集中的元数据中获取，对于在其它程序集中定义的类型，CLR会通过一组规则来在磁盘中找到该程序集并加载在内存。

CLR在查找引用的程序集的位置时候，第一个判断条件是 判断该程序集是否被签名。
什么是签名？

#### 强名称程序集
就比如大家都叫张三，姓名都一样，喊一声张三不知道到底在叫谁。这时候我们就必须扩展一下这个名字以让它具有唯一性。

我们可以通过sn.exe或VS对项目右键属性在签名选项卡中采取RSA算法对程序集进行数字签名（加密：公钥加密，私钥解密。签名：私钥签名，公钥验证签名），会将构成程序集的所有文件通过哈希算法生成哈希值，然后通过非对称加密算法用私钥签名，最后公布公钥生成一串token，最终将生成一个由程序集名称、版本号、语言文化、公钥组成的唯一标识，它相当于一个强化的名称，即强名称程序集。
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

我们日常在VS中的项目默认都没有被签名，所以就是弱名称程序集。强名称程序集是具有唯一标识性的程序集，并且可以通过对比哈希值来比较程序集是否被篡改，不过仍然有很多手段和软件可以去掉程序集的签名。

需要值得注意的一点是：当你试图在已生成好的强名称程序集中引用弱名称程序集，那么你必须对弱名称程序集进行签名并在强名称程序集中重新注册。
之所以这样是因为一个程序集是否被篡改还要考虑到该程序集所引用的那些程序集，根据CLR搜索程序集的规则(下文会介绍)，没有被签名的程序集可以被随意替换，所以考虑到安全性，强名称程序集必须引用强名称程序集，否则就会报错：需要强名称程序集。

.NET Framework 4.5中对强签名的更改：https://docs.microsoft.com/zh-cn/dotnet/framework/app-domains/enhanced-strong-naming

#### 程序集搜索规则
事实上，按照存储位置来说，程序集分为共享(全局)程序集和私有程序集。

CLR查找程序集的时候，会先判断该程序集是否被强签名，如果强签名了那么就会去共享程序集的存储位置(后文的GAC)去找，如果没找到或者该程序集没有被强签名，那么就从该程序集的同一目录下去寻找。

强名称程序集是先找到与程序集名称(VS中对项目右键属性应用程序->程序集名称)相等的文件名称，然后 按照唯一标识再来确认，确认后CLR加载程序集，同时会通过公钥效验该签名来验证程序集是否被篡改(如果想跳过验证可查阅https://docs.microsoft.com/zh-cn/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature)，如果强名称程序集被篡改则报错。

而弱名称程序集则直接按照与程序集名称相等的文件名称来找，如果还是没有找到就以该程序集名称为目录的文件夹下去找。总之，如果最终结果就是没找到那就会报System.IO.FileNotFoundException异常，即尝试访问磁盘上不存在的文件失败时引发的异常。

注意：此处文件名称和程序集名称是两个概念，不要模棱两可，文件CLR头内嵌程序集名称。

举个例子：
我有一个控制台程序，其路径为D:\Demo\Debug\demo.exe，通过该程序的元数据得知，其引用了一个程序集名称为aa的普通程序集，引用了一个名为bb的强名称程序集，该bb.dll的强名称标识为：xx001。
现在CLR开始搜索程序集aa，首先它会从demo.exe控制台的同一目录(也就是D:\Demo\Debug\)中查找程序集aa，搜索文件名为aa.dll的文件，如果没找到就在该目录下以程序集名称为目录的目录中查找，也就是会查 D:\Demo\Debug\aa\aa.dll，这也找不到那就报错。
然后CLR开始搜索程序集bb，CLR从demo.exe的元数据中发现bb是强名称程序集，其标识为:xx001。于是CLR会先从一个被定义为GAC的目录中去通过标识找，没找到的话剩下的寻找步骤就和寻找aa一样完全一致了。

当然，你也可以通过配置文件config中(配置文件存在于应用程序的同一目录中)人为增加程序集搜索规则：
1.在运行时runtime节点中，添加privatePath属性来添加搜索目录，不过只能填写相对路径： 
```xml
<runtime>
            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                <probing privatePath="relative1;relative2;" /> //程序集当前目录下的相对路径目录，用;号分割
            </assemblyBinding>
</runtime>
```

2.如果程序集是强签名后的，那么可以通过codeBase来指定网络路径或本地绝对路径。
```xml
<runtime>
            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                <dependentAssembly>
                    <assemblyIdentity name="myAssembly"
                                      publicKeyToken="32ab4ba45e0a69a1"
                                      culture="neutral" />
                    <codeBase version="2.0.0.0"
                              href="http://www.CodeSnippet.cn/myAssembly.dll" />
                </dependentAssembly>
            </assemblyBinding>
</runtime>
```

当然，我们还可以在代码中通过AppDomain类中的几个成员来改变搜索规则，如AssemblyResolve事件、AppDomainSetup类等。

有关运行时节点的描述:https://docs.microsoft.com/zh-cn/dotnet/framework/configure-apps/file-schema/runtime/runtime-element

#### 项目的依赖顺序
如果没有通过config或者在代码中来设定CLR搜索程序集的规则，那么CLR就按照默认的也就是我上述所说的模式来寻找。
所以如果我们通过csc.exe来编译项目，引用了其它程序集的话，通常需要将那些程序集复制到同一目录下。故而每当我们通过VS编译器对项目右键重新生成项目(重新编译)时，VS都会将引用的程序集给复制一份到项目bin\输出目录Debug文件夹下，我们可以通过VS中对引用的程序集右键属性-复制本地 True/Flase 来决定这一默认行为。
值得一提的是，项目间的生成是有序生成的，它取决于项目间的依赖顺序。
比如Web项目引用BLL项目，BLL项目引用了DAL项目。那么当我生成Web项目的时候，因为我要注册Bll程序集，所以我要先生成Bll程序集，而BLL程序集又引用了Dal，所以又要先生成Dal程序集，所以程序集生成顺序就是Dal=>BLL=>Web，项目越多编译的时间就越久。

程序集之间的依赖顺序决定了编译顺序，所以在设计项目间的分层划分时不仅要体现出层级职责，还要考虑到依赖顺序。代码存放在哪个项目要有讲究，不允许出现互相引用的情况，比如A项目中的代码引用B，B项目中的代码又引用A。

#### 为什么Newtonsoft.Json版本不一致？
而除了注意编译顺序外，我们还要注意程序集间的版本问题，版本间的错乱会导致程序的异常。

举个经典的例子：Newtonsoft.Json的版本警告，大多数人都知道通过版本重定向来解决这个问题，但很少有人会琢磨为什么会出现这个问题，找了一圈文章，没找到一个解释的。
比如：
A程序集引用了 C盘:\Newtonsoft.Json 6.0程序集
B程序集引用了 从Nuget下载下来的Newtonsoft.Json 10.0程序集
此时A引用B，就会报：发现同一依赖程序集的不同版本间存在无法解决的冲突 这一警告。
```csharp
A：引用Newtonsoft.Json 6.0
Func()
{
	var obj= Newtonsoft.Json.Obj;
	B.JsonObj();
}

B: 引用Newtonsoft.Json 10.0
JsonObj()
 {
	 return  Newtonsoft.Json.Obj;
 }
```
A程序集中的Func方法调用了B程序集中的JsonObj方法，JsonObj方法又调用了Newtonsoft.Json 10.0程序集中的对象，那么当执行Func方法时程序就会异常，报System.IO.FileNotFoundException: 未能加载文件或程序集Newtonsoft.Json 10.0的错误。

这是为什么？
1.这是因为依赖顺序引起的。A引用了B，首先会先生成B，而B引用了 Newtonsoft.Json 10.0，那么VS就会将源引用文件(Newtonsoft.Json 10.0)复制到B程序集同一目录(bin/Debug)下，名为Newtonsoft.Json.dll文件，其内嵌程序集版本为10.0。
2.然后A引用了B，所以会将B程序集和B程序集的依赖项(Newtonsoft.Json.dll)给复制到A的程序集目录下，而A又引用了C盘的Newtonsoft.Json 6.0程序集文件，所以又将C:\Newtonsoft.Json.dll文件给复制到自己程序集目录下。因为两个Newtonsoft.Json.dll重名，所以直接覆盖了前者，那么只保留了Newtonsoft.Json 6.0。
3.当我们调用Func方法中的B.Convert()时候，CLR会搜索B程序集，找到后再调用 return Newtonsoft.Json.Obj 这行代码，而这行代码又用到了Newtonsoft.Json程序集，接下来CLR搜索Newtonsoft.Json.dll，文件名称满足，接下来CLR判断其标识，发现版本号是6.0，与B程序集清单里注册的10.0版本不符，故而才会报出异常：未能加载文件或程序集Newtonsoft.Json 10.0。
以上就是为何Newtonsoft.Json版本不一致会导致错误的原因，其也诠释了CLR搜索程序集的一个过程。
那么，如果我执意如此，有什么好的解决方法能让程序顺利执行呢？有，有2个方法。

第一种：通过bindingRedirect节点重定向，即当找到10.0的版本时，给定向到6.0版本
```xml
<runtime>
            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                <dependentAssembly>
                    <assemblyIdentity name="Newtonsoft.Json"
                                      publicKeyToken="30ad4fe6b2a6aeed"
                                      culture="neutral" />
                    <bindingRedirect oldVersion="10.0.0.0"
                                     newVersion="6.0.0.0" />
                </dependentAssembly>
            </assemblyBinding>
</runtime>
```

#### 如何在编译时加载两个相同的程序集？
注意：我看过有的文章里写的一个AppDomain只能加载一个相同的程序集，很多人都以为不能同时加载2个不同版本的程序集，实际上CLR是可以同时加载Newtonsoft.Json 6.0和Newtonsoft.Json 10.0的。

第二种：对每个版本指定codeBase路径，然后分别放上不同版本的程序集，这样就可以加载两个相同的程序集。
```xml
<runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Newtonsoft.Json"
                                  publicKeyToken="30ad4fe6b2a6aeed"
                                  culture="neutral" />
                <codeBase version="6.0.0.0"
                          href="D:\6.0\Newtonsoft.Json.dll" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Newtonsoft.Json"
                                  publicKeyToken="30ad4fe6b2a6aeed"
                                  culture="neutral" />
                <codeBase version="10.0.0.0"
                          href="D:\10.0\Newtonsoft.Json.dll" />
            </dependentAssembly>
        </assemblyBinding>
</runtime>
```

#### 如何同时调用两个两个相同命名空间和类型的程序集？
除了程序集版本不同外，还有一种情况就是，我一个项目同时引用了程序集A和程序集B，但程序集A和程序集B中的命名空间和类型名称完全一模一样，这个时候我调用任意一个类型都无法区分它是来自于哪个程序集的，那么这种情况我们可以使用extern alias外部别名。
我们需要在所有代码前定义别名，extern alias a;extern alias b;，然后在VS中对引用的程序集右键属性-别名，分别将其更改为a和b(或在csc中通过/r:{别名}={程序集}.dll)。
在代码中通过 {别名}::{命名空间}.{类型}的方式来使用。
extern-alias介绍： https://docs.microsoft.com/zh-cn/dotnet/csharp/language-reference/keywords/extern-alias

#### 共享程序集GAC
我上面说了这么多有关CLR加载程序集的细节和规则，事实上，类似于mscorlib.dll、System.dll这样的FCL类库被引用的如此频繁，它已经是我们.NET编程中必不可少的一部分，几尽每个项目都会引用，为了不再每次使用的时候都复制一份，所以计算机上有一个位置专门存储这些我们都会用到的程序集，叫做全局程序集缓存(Global Assembly Cache,GAC)，这个位置一般位于C:\Windows\Microsoft.NET\assembly和3.5之前版本的C:\Windows\assembly。
既然是共享存放的位置，那不可避免的会遇到文件名重复的情况，那么为了杜绝该类情况，规定在GAC中只能存在强名称程序集，每当CLR要加载强名称程序集时，会先通过标识去GAC中查找，而考虑到程序集文件名称一致但版本文化等复杂的情况，所以GAC有自己的一套目录结构。我们如果想将自己的程序集放入GAC中，那么就必须先签名，然后通过如gacutil.exe工具(其存在于命令行工具中 https://docs.microsoft.com/zh-cn/dotnet/framework/tools/developer-command-prompt-for-vs中)来注册至GAC中，值得一提的是在将强名称程序集安装在GAC中，会效验签名。

GAC工具： https://docs.microsoft.com/en-us/dotnet/framework/tools/gacutil-exe-gac-tool

#### 延伸
CLR是按需加载程序集的，没有执行代码也就没有调用相应的指令，没有相应的指令，CLR也不会对其进行相应的操作。 当我们执行Environment.CurrentDirectory这段代码的时候，CLR首先要获取Environment类型信息，通过自身元数据得知其存在mscorlib.dll程序集中，所以CLR要加载该程序集，而mscorlib.dll又由于其地位特殊，早在CLR初始化的时候就已经被类型加载器自动加载至内存中，所以这行代码可以直接在内存中读取到类型的方法信息。
在这个章节，我虽然描述了CLR搜索程序集的规则，但事实上，加载程序集读取类型信息远远没有这么简单，这涉及到了属于.NET Framework独有的"应用程序域"概念和内存信息的查找。

简单延伸两个问题，mscorlib.dll被加载在哪里？内存堆中又是什么样的一个情况？

这里⇓感觉得写点什么，要不显得有点空，但还没想好写什么... 返回顶部