VB.net 2010 视频教程 VB.net 2010 视频教程 python基础视频教程
SQL Server 2008 视频教程 c#入门经典教程 Visual Basic从门到精通视频教程
当前位置:
首页 > Python基础教程 >

  • C#教程之通俗易懂，什么是.NET?什么是.NET Framewo

什么是.NET？什么是.NET Framework?本文将从上往下，循序渐进的介绍一系列相关.NET的概念，先从类型系统开始讲起，我将通过跨语言操作这个例子来逐渐引入一系列.NET的相关概念，这主要包括：CLS、CTS(CLI)、FCL、Windows下CLR的相关核心组成、Windows下托管程序运行概念、什么是.NET Framework，.NET Core，.NET Standard及一些VS编译器相关杂项和相关阅读链接。完整的从上读到下则你可以理解个大概的.NET体系。

文章是我一字一字亲手码出来的，每天下班用休息时间写一点，持续了二十来天。且对于文章上下衔接、概念引入花了很多心思，致力让很多概念在本文中显得通俗。但毕竟.NET系统很庞大，本文篇幅有限，所以在部分小节中我会给出延伸阅读的链接，在文章结尾我给出了一些小的建议，希望能对需要帮助的人带来帮助，如果想与我交流可以文章留言或者加.NET技术交流群：166843154

目录

  • .NET和C#是什么关系
  • 跨语言和跨平台是什么
  • 什么是跨语言互操作，什么是CLS
    • CLS异常
  • 什么是CTS？
  • 什么是类库？
    • 什么是基础类库BCL？
    • 什么是框架类库FCL？
  • 什么是基元类型？
  • System.Object的意义
  • 计算机是如何运行程序的？
    • 什么是CPU？
    • 什么是高级编程语言？
  • 什么是托管代码，托管语言，托管模块？
    • 非托管的异常
  • 什么是CLR，.NET虚拟机？
  • 什么是CLR宿主进程，运行时主机？
  • Windows系统自带.NET Framework
  • .NET Framework 4.0.30319
    • .NET Framework4.X覆盖更新
    • 如何确认本机安装了哪些.NET Framework和对应CLR的版本？
  • 什么是程序集
  • 用csc.exe进行编译
  • .NET程序执行原理
    • JIT编译
    • AOT编译
  • 程序集的规则
    • 程序集的加载方式
    • 强名称程序集
    • 程序集搜索规则
    • 项目的依赖顺序
    • 为什么Newtonsoft.Json版本不一致？
    • 如何在编译时加载两个相同的程序集
    • 如何同时调用两个两个相同命名空间和类型的程序集？
    • 共享程序集GAC
    • 延伸
  • 应用程序域
    • 跨边界访问
    • AppDomain和AppPool
  • 内存
    • 堆栈和堆的区别
    • 线程堆栈
    • 为什么值类型存储在栈上
    • 托管堆模型
    • 选class还是struct
    • GC管理器
    • 弱引用、弱事件
    • GC堆回收
    • 垃圾回收对性能的影响
    • 性能建议
  • .NET程序执行图
  • .NET的安全性
    • 基于角色的安全性
    • 代码访问安全性
  • 什么是.NET
    • 什么是.NET Framework
      • 如何在VS中调试.NET Framework源代码
    • 什么是.NET Core
    • 什么是.NET Standard
    • .NET官方开源项目链接
  • Visual Studio
    • sln解决方案
    • 项目模板
    • csproj工程文件
    • 项目属性杂项
    • IntelliTrace智能追溯
    • 链接
  • 建议

.NET和C#是什么关系

语言，是人们进行沟通表达的主要方式。编程语言，是人与机器沟通的表达方式。不同的编程语言，其侧重点不同。有的编程语言是为了科学计算而开发的，所以其语法和功能更偏向于函数式思想。有些则是为了开发应用程序而创立的，所以其语法和功能更为均衡全面。

微软公司是全球最大的电脑软件提供商，为了占据开发者市场，进而在2002年推出了Visual Studio(简称VS，是微软提供给开发者的工具集) .NET 1.0版本的开发者平台。而为了吸引更多的开发者涌入平台，微软还在2002年宣布推出一个特性强大并且与.NET平台无缝集成的编程语言，即C# 1.0正式版。
只要是.NET支持的编程语言，开发者就可以通过.NET平台提供的工具服务和框架支持便捷的开发应用程序。

C#就是为宣传.NET而创立的，它直接集成于Visual Studio .NET中，VB也在.NET 1.0发布后对其进行支持， 所以这两门语言与.NET平台耦合度很高，并且.NET上的技术大多都是以C#编程语言为示例，所以经常就.NET和C#混为一谈(实质上它们是相辅相成的两个概念)。
而作为一个开发者平台，它不仅仅是包含开发环境、技术框架、社区论坛、服务支持等，它还强调了平台的跨语言、跨平台编程的两个特性。

跨语言和跨平台是什么

跨语言：即只要是面向.NET平台的编程语言((C#、Visual Basic、C++/CLI、Eiffel、F#、IronPython、IronRuby、PowerBuilder、Visual COBOL 以及 Windows PowerShell))，用其中一种语言编写的类型可以无缝地用在另一种语言编写的应用程序中的互操作性。
跨平台：一次编译，不需要任何代码修改，应用程序就可以运行在任意有.NET框架实现的平台上，即代码不依赖于操作系统，也不依赖硬件环境。

什么是跨语言互操作，什么是CLS

每门语言在最初被设计时都有其在功能和语法上的定位，让不同的人使用擅长的语言去干合适的事，这在团队协作时尤为重要。
.NET平台上的跨语言是通过CLS这个概念来实现的，接下来我就以C#和VB来演示 什么是.NET中的跨语言互操作性。

通俗来说，虽然c#和vb是两个不同的语言，但此处c#写的类可以在vb中当做自家写的类一样正常使用。

比如我在vb中写了一个针对String的首字母大写的扩展方法，将其编译后的dll引用至C#项目中。

在C#项目中，可以像自身代码一样正常使用来自vb这个dll的扩展方法。

现在有那么多面向对象语言，但不是所有编程语言都能这样直接互操作使用，而.NET平台支持的C#和VB之所以能这样无缝衔接，先读而后知，后文将会介绍缘由。不过虽然.NET平台提供了这样一个互操作的特性，但终究语言是不一样的，每个语言有其特色和差异处，在相互操作的时候就会难免遇到一些例外情况。

比如我在C#中定义了一个基类，类里面包含一个公开的指针类型的成员，我想在vb中继承这个类，并访问这个公开的成员。

但是vb语言因为其定位不需要指针，所以并没有C#中如int*这样的指针类型，所以在vb中访问一个该语言不支持的类型会报错的，会提示：字段的类型不受支持。

再比如，C#语言中，对类名是区分大小写的，我在C#中定义了两个类，一个叫BaseBusiness，另一个叫baseBusiness。我在vb中去继承这个BaseBusiness类。

如图，在vb中访问这个类会报错的，报:"BaseBusiness"不明确，这是因为在vb中对类名是不区分大小写的。在vb中，它认为它同时访问了两个一模一样的类，所以按照vb的规则这是不合理的。那么为了在vb调用c#的程序集中避免这些因语言的差异性而导致的错误，在编写c#代码的时候 就应该提前知道vb中的这些规则，来应付式的开发。 

但是，如果我想不仅仅局限于C#和VB，我还想我编写的代码在.Net平台上通用的话，那么我还必须得知道.NET平台支持的每一种语言和我编写代码所使用的语言的差异，从而在编写代码中避免这些。

这几年编程语言层出不穷，在将来.NET可能还会支持更多的语言，如果说对一个开发者而言掌握所有语言的差异处这是不现实的，所以.NET专门为此参考每种语言并找出了语言间的共性，然后定义了一组规则，开发者都遵守这个规则来编码，那么代码就能被任意.NET平台支持的语言所通用。
而与其说是规则，不如说它是一组语言互操作的标准规范，它就是公共语言规范 - Common Language Specification ,简称CLS

 CLS从类型、命名、事件、属性、数组等方面对语言进行了共性的定义及规范。这些东西被提交给欧洲计算机制造联合会ECMA，称为：共同语言基础设施。

就以类型而言，CLS定义了在C#语言中符合规范的类型和不符合的有：

当然，就编码角度而言，我们不是必须要看那些详略的文档。为了方便开发者开发，.NET提供了一个特性，名叫：CLSCompliantAttribute，代码被CLSCompliantAttribute标记后，如果你写的代码不符合CLS规范的话，编译器就会给你一条警告。

 

值得一提的是，CLS规则只是面向那些公开可被其它程序集访问的成员，如public、继承的protected，对于该程序集的内部成员如Private、internal则不会执行该检测规则。也就是说，所适应的CLS遵从性规则，仅是那些公开的成员，而非私有实现。

那么有没有那种特殊情况，比如我通过反射技术来访问该程序集中，当前语言并不拥有的类型时会发生什么情况呢？

答案是可以尝试的，如用vb反射访问c#中的char*指针类型，即使vb中没有char*这种等价的指针类型，但mscorlib提供了针对指针类型的 Pointer 包装类供其访问，可以从运行时类携带的类型名称看到其原本的类型名。

可以看到，该类中的元素是不符合CLS规范的。

CLS异常

提到特殊情况，还要说的一点就是异常处理。.NET框架组成中定义了异常类型系统，在编译器角度，所有catch捕获的异常都必须继承自System.Exception，如果你要调用一个 由不遵循此规范的语言 抛出其它类型的异常对象(C++允许抛出任何类型的异常，如C#调用C++代码，C++抛出一个string类型的异常)，在C#2.0之前Catch(Exception)是捕捉不了的，但之后的版本可以。
在后续版本中，微软提供了System.Runtime.CompilerServices.RuntimeWrappedException异常类，将那些不符合CLS的包含Exception的对象封装起来。并且可以通过RuntimeCompatibilityAttribute特性来过滤这些异常。
RuntimeWrappedException ：https://docs.microsoft.com/zh-cn/dotnet/api/system.runtime.compilerservices.runtimewrappedexception?view=netframework-4.7.2

那么，这个段落总结一下，什么是CLS呢？

在面向.NET开发中，编写跨语言组件时所遵循的那些共性，那些规范就叫做 Common Langrage Specification简称 CLS，公共语言规范 
官方CLS介绍：https://docs.microsoft.com/zh-cn/dotnet/standard/language-independence-and-language-independent-components

什么是CTS？

如果理解了什么是CLS的话，那么你将很轻松理解什么是CTS。
假设你已经围绕着封装 继承 多态 这3个特性设计出了多款面向对象的语言，你发现大家都是面向对象，都能很好的将现实中的对象模型表达出来。除了语法和功能擅长不同，语言的定义和设计结构其实都差不多一回事。

比如，现实中你看到了一辆小汽车，这辆车里坐着两个人，那么如何用这门语言来表达这样的一个概念和场面？
首先要为这门语言横向定义一个“类型”的概念。接下来在程序中就可以这样表示：有一个汽车类型，有一个人类型，在一个汽车类型的对象内包含着两个人类型的对象，因为要表达出这个模型，你又引入了“对象”的概念 。而现在，你又看到，汽车里面的人做出了开车的这样一个动作，由此你又引入了“动作指令”这样一个概念。
接着，你又恍然大悟总结出一个定理，无论是什么样的“类型”，都只会存在这样一个特征，即活着的 带生命特征的(如人) 和 死的 没有生命特征的(如汽车) 这两者中的一个。最后，随着思想模型的成熟，你发现，这个“类型”就相当于一个富有主体特征的一组指令的集合。
好，然后你开始照葫芦画瓢。你参考其它程序语言，你发现大家都是用class来表示类的含义，用struct表示结构的含义，用new来表示 新建一个对象的含义，于是，你对这部分功能的语法也使用class和new关键字来表示。然后你又发现，他们还用很多关键字来更丰富的表示这些现实模型，比如override、virtual等。于是，在不断的思想升级和借鉴后，你对这个设计语言过程中思想的变化仔细分析，对这套语言体系给抽象归纳，最终总结出一套体系。

于是你对其它人这样说，我总结出了一门语言很多必要的东西如两种主要类别：值类别和引用类别，五个主要类型：类、接口、委托、结构、枚举，我还规定了，一个类型可以包含字段、属性、方法、事件等成员，我还指定了每种类型的可见性规则和类型成员的访问规则，等等等等，只要按照我这个体系来设计语言，设计出来的语言它能够拥有很多不错的特性，比如跨语言，跨平台等，C#和VB.net之所以能够这样就是因为这两门语言的设计符合我这个体系。

那么，什么是CTS呢？

当你需要设计面向.Net的语言时所需要遵循一个体系(.Net平台下的语言都支持的一个体系)这个体系就是CTS（Common Type System 公共类型系统），它包括但不限于：

  • 建立用于跨语言执行的框架。
  • 提供面向对象的模型，支持在 .NET 实现上实现各种语言。
  • 定义处理类型时所有语言都必须遵守的一组规则(CLS)。
  • 提供包含应用程序开发中使用的基本基元数据类型（如 Boolean、Byte、Char 等）的库。

上文的CLS是CTS（Common Type System 公共类型系统）这个体系中的子集。
一个编程语言，如果它能够支持CTS，那么我们就称它为面向.NET平台的语言。
官方CTS介绍： https://docs.microsoft.com/zh-cn/dotnet/standard/common-type-system

微软已经将CTS和.NET的一些其它组件，提交给ECMA以成为公开的标准，最后形成的标准称为CLI（Common Language Infrastructure）公共语言基础结构。
所以有的时候你见到的书籍或文章有的只提起CTS，有的只提起CLI，请不要奇怪，你可以宽泛的把他们理解成一个意思，CLI是微软将CTS等内容提交给国际组织计算机制造联合会ECMA的一个工业标准。

什么是类库？

在CTS中有一条就是要求基元数据类型的类库。我们先搞清什么是类库？类库就是类的逻辑集合，你开发工作中你用过或自己编写过很多工具类，比如搞Web的经常要用到的 JsonHelper、XmlHelper、HttpHelper等等，这些类通常都会在命名为Tool、Utility等这样的项目中。 像这些类的集合我们可以在逻辑上称之为 "类库"，比如这些Helper我们统称为工具类库。

什么是基础类库BCL？

当你通过VS创建一个项目后，你这个项目就已经引用好了通过.NET下的语言编写好的一些类库。比如控制台中你直接就可以用ConSole类来输出信息，或者using System.IO 即可通过File类对文件进行读取或写入操作，这些类都是微软帮你写好的，不用你自己去编写，它帮你编写了一个面向.NET的开发语言中使用的基本的功能，这部分类，我们称之为BCL（Base Class Library）， 基础类库，它们大多都包含在System命名空间下。

基础类库BCL包含：基本数据类型，文件操作，集合，自定义属性，格式设置，安全属性，I/O流，字符串操作，事件日志等的类型

什么是框架类库FCL？

有关BCL的就不在此一一类举。.NET之大，发展至今，由微软帮助开发人员编写的类库越来越多，这让我们开发人员开发更加容易。由微软开发的类库统称为：FCL，Framework Class Library ，.NET框架类库，我上述所表达的BCL就是FCL中的一个基础部分，FCL中大部分类都是通过C#来编写的。

在FCL中，除了最基础的那部分BCL之外，还包含我们常见的 如 ： 用于网站开发技术的 ASP.NET类库，该子类包含webform/webpage/mvc，用于桌面开发的 WPF类库、WinForm类库，用于通信交互的WCF、asp.net web api、Web Service类库等等

什么是基元类型？

像上文在CTS中提到了 基本基元数据类型，大家知道，每门语言都会定义一些基础的类型，比如C#通过 int 来定义整型，用 string 来定义 字符串 ，用 object 来定义 根类。当我们来描述这样一个类型的对象时可以有这两种写法，如图：

我们可以看到，上边用首字母小写的蓝色体string、object能描述，用首字母大写的浅蓝色String、Object也能描述,这两种表述方式有何不同？

要知道，在vs默认的颜色方案中，蓝色体 代表关键字，浅蓝色体 代表类型。
那么这样也就意味着，由微软提供的FCL类库里面 包含了 一些用于描述数据类型的 基础类型，无论我们使用的是什么语言，只要引用了FCL，我们都可以通过new一个类的方式来表达数据类型。
如图：

用new来创建这些类型的对象，但这样就太繁琐，所以C#就用 int关键字来表示System.Int32，用 string关键字来表示 System.String等，所以我们才能这样去写。

像这样被表述于编译器直接支持的类型叫做基元类型，它被直接映射于BCL中具体的类。

下面是部分面向.NET的语言的基元类型与对应的BCL的类别图 ：

System.Object的意义

说起类型，这里要说CTS定义的一个非常重要的规则，就是类与类之间只能单继承，System.Object类是所有类型的根，任何类都是显式或隐式的继承于System.Object。

    System.Object定义了类型的最基本的行为：用于实例比较的Equals系列方法、用于Hash表中Hash码的GetHashCode、用于Clr运行时获取的类型信息GetType、用于表示当前对象字符串的ToString、用于执行实例的浅复制MemberwiseClone、用于GC回收前操作的析构方法Finalize 这6类方法。

所以 Object不仅是C#语言的类型根、还是VB等所有面向.NET的语言的类型根，它是整个FCL的类型根。

   当然，CTS定义了单继承，很多编程语言都满足这个规则，但也有语言是例外，如C++就不做继承限制，可以继承多个，C++/CLI作为C++在对.NET的CLI实现，如果在非托管编码中多继承那也可以，如果试图在托管代码中多继承，那就会报错。我前面已经举过这样特殊情况的例子，这也在另一方面反映出，各语言对CTS的支持并不是都如C#那样全面的，我们只需明记一点：对于符合CTS的那部分自然就按照CTS定义的规则来。 任何可遵循CTS的类型规范，同时又有.NET运行时的实现的编程语言就可以成为.NET中的一员。

计算机是如何运行程序的？

接下来我要说什么是.NET的跨平台，并解释为什么能够跨语言。不过要想知道什么是跨平台，首先你得知道一个程序是如何在本机上运行的。

什么是CPU

CPU,全称Central Processing Unit,叫做中央处理器,它是一块超大规模的集成电路，是计算机组成上必不可少的组成硬件，没了它，计算机就是个壳。
无论你编程水平怎样，你都应该先知道，CPU是一台计算机的运算核心和控制核心，CPU从存储器或高速缓冲存储器中取出指令，放入指令寄存器，并对指令译码，执行指令。
我们运行一个程序，CPU就会不断的读取程序中的指令并执行，直到关闭程序。事实上，从电脑开机开始，CPU就一直在不断的执行指令直到电脑关机。

什么是高级编程语言

在计算机角度，每一种CPU类型都有自己可以识别的一套指令集，计算机不管你这个程序是用什么语言来编写的，其最终只认其CPU能够识别的二进制指令集。
在早期计算机刚发展的时代，人们都是直接输入01010101这样的没有语义的二进制指令来让计算机工作的，可读性几乎没有，没人愿意直接编写那些没有可读性、繁琐、费时，易出差错的二进制01代码，所以后来才出现了编程语言。

编程语言的诞生，使得人们编写的代码有了可读性，有了语义，与直接用01相比，更有利于记忆。
而前面说了，计算机最终只识别二进制的指令，那么，我们用编程语言编写出来的代码就必须要转换成供机器识别的指令。
就像这样：

复制代码
code: 1+2 
function 翻译方法(参数:code) 
{ 
    ... 
    "1"=>"001"; 
    "2"=>"002";
    "+"=>"000"; 
    return 能让机器识别的二进制代码; 
} 
call 翻译方法("1+2") => "001 000 002"
复制代码

所以从一门编程语言所编写的代码文件转换成能让本机识别的指令，这中间是需要一个翻译的过程。
而我们现在计算机上是运载着操作系统的，光翻译成机器指令也不行，还得让代码文件转化成可供操作系统执行的程序才行。
那么这些步骤，就是编程语言所对应的编译环节的工程了。这个翻译过程是需要工具来完成，我们把它叫做 编译器。

不同厂商的CPU有着不同的指令集，为了克服面向CPU的指令集的难读、难编、难记和易出错的缺点，后来就出现了面向特定CPU的特定汇编语言， 比如我打上这样的x86汇编指令 mov ax,bx ，然后用上用机器码做的汇编器，它将会被翻译成 1000100111011000 这样的二进制01格式的机器指令.

不同CPU架构上的汇编语言指令不同，而为了统一一套写法，同时又不失汇编的表达能力，C语言就诞生了。
用C语言写的代码文件，会被C编译器先转换成对应平台的汇编指令，再转成机器码，最后将这些过程中产生的中间模块链接成一个可以被操作系统执行的程序。

那么汇编语言和C语言比较，我们就不需要去阅读特定CPU的汇编码，我只需要写通用的C源码就可以实现程序的编写，我们用将更偏机器实现的汇编语言称为低级语言，与汇编相比，C语言就称之为高级语言。

在看看我们C#，我们在编码的时候都不需要过于偏向特定平台的实现，翻译过程也基本遵循这个过程。它的编译模型和C语言类似，都是属于这种间接转换的中间步骤，故而能够跨平台。
所以就类似于C/C#等这样的高级语言来说是不区分平台的，而在于其背后支持的这个 翻译原理 是否能支持其它平台。

什么是托管代码，托管语言，托管模块？

作为一门年轻的语言，C#借鉴了许多语言的长处，与C比较，C#则更为高级。
往往一段简小的C#代码，其功能却相当于C的一大段代码，并且用C#语言你几乎不需要指针的使用，这也就意味着你几乎不需要进行人为的内存管控与安全考虑因素，也不需要多懂一些操作系统的知识，这让编写程序变得更加轻松和快捷。

如果说C#一段代码可以完成其它低级语言一大段任务，那么我们可以说它特性丰富或者类库丰富。而用C#编程不需要人为内存管控是怎么做到的呢？
    .NET提供了一个垃圾回收器(GC)来完成这部分工作，当你创建类型的时候，它会自动给你分配所需要的这部分内存空间。就相当于，有一个专门的软件或进程，它会读取你的代码，然后当你执行这行代码的时候，它帮你做了内存分配工作。 这部分本该你做的工作，它帮你做了，这就是“托管”的概念。比如现实中 托管店铺、托管教育等这样的别人替你完成的概念。

因此，C#被称之为托管语言。C#编写的代码也就称之为托管代码,C#生成的模块称之为托管模块等。(对于托管的资源，是不需要也无法我们人工去干预的，但我们可以了解它的一些机制原理，在后文我会简单介绍。)

只要有比较，就会产生概念。那么在C#角度，那些脱离了.NET提供的诸如垃圾回收器这样的环境管制，就是对应的 非托管了。

非托管的异常

我们编写的程序有的模块是由托管代码编写，有的模块则调用了非托管代码。在.NET Framework中也有一套基于此操作系统SEH的异常机制，理想的机制设定下我们可以直接通过catch(e)或catch来捕获指定的异常和框架设计人员允许我们捕获的异常。

而异常类型的级别也有大有小，有小到可以直接框架本身或用代码处理的，有大到需要操作系统的异常机制来处理。.NET会对那些能让程序崩溃的异常类型给进行标记，对于这部分异常，在.NET Framework 4.0之前允许开发人员在代码中自己去处理，但4.0版本之后有所变更，这些被标记的异常默认不会在托管环境中抛出(即无法catch到)，而是由操作系统的SEH机制去处理。 
不过如果你仍然想在代码中捕获处理这样的异常也是可以的，你可以对需要捕获的方法上标记[System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute]特性，就可以在该方法内通过catch捕获到该类型的异常。你也可以通过在配置文件中添加运行时节点来对全局进行这样的一个配置：

<runtime>
     <legacyCorruptedStateExceptionsPolicy enabled="true" />
</runtime>

HandleProcessCorruptedStateExceptions特性：https://msdn.microsoft.com/zh-cn/library/azure/system.runtime.exceptionservices.handleprocesscorruptedstateexceptionsattribute.aspx 
SEHException类：https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.sehexception(v=vs.100).aspx 
处理损坏状态异常博客专栏： https://msdn.microsoft.com/zh-cn/magazine/dd419661.aspx

什么是CLR，.NET虚拟机？

实际上，.NET不仅提供了自动内存管理的支持，他还提供了一些列的如类型安全、应用程序域、异常机制等支持，这些 都被统称为CLR公共语言运行库。

CLR是.NET类型系统的基础，所有的.NET技术都是建立在此之上，熟悉它可以帮助我们更好的理解框架组件的核心、原理。
在我们执行托管代码之前，总会先运行这些运行库代码，通过运行库的代码调用，从而构成了一个用来支持托管程序的运行环境，进而完成诸如不需要开发人员手动管理内存，一套代码即可在各大平台跑的这样的操作。

这套环境及体系之完善，以至于就像一个小型的系统一样，所以通常形象的称CLR为".NET虚拟机"。那么，如果以进程为最低端，进程的上面就是.NET虚拟机(CLR)，而虚拟机的上面才是我们的托管代码。换句话说，托管程序实际上是寄宿于.NET虚拟机中。

什么是CLR宿主进程，运行时主机？

那么相对应的，容纳.NET虚拟机的进程就是CLR宿主进程了，该程序称之为运行时主机。

这些运行库的代码，全是由C/C++编写，具体表现为以mscoree.dll为代表的核心dll文件，该dll提供了N多函数用来构建一个CLR环境 ，最后当运行时环境构建完毕(一些函数执行完毕)后，调用_CorDllMain或_CorExeMain来查找并执行托管程序的入口方法(如控制台就是Main方法)。

如果你足够熟悉CLR，那么你完全可以在一个非托管程序中通过调用运行库函数来定制CLR并执行托管代码。
像SqlServer就集成了CLR，可以使用任何 .NET Framework 语言编写存储过程、触发器、用户定义类型、用户定义函数（标量函数和表值函数）以及用户定义的聚合函数。

有关CLR大纲介绍： https://msdn.microsoft.com/zh-cn/library/9x0wh2z3(v=vs.85).aspx 
CLR集成： https://docs.microsoft.com/zh-cn/previous-versions/sql/sql-server-2008/ms131052(v%3dsql.100) 
构造CLR的接口：https://msdn.microsoft.com/zh-cn/library/ms231039(v=vs.85).aspx 
适用于 .NET Framework 2.0 的宿主接口：https://msdn.microsoft.com/zh-cn/library/ms164336(v=vs.85).aspx
选择CLR版本： https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/startup/supportedruntime-element

所以C#编写的程序如果想运行就必须要依靠.NET提供的CLR环境来支持。 而CLR是.NET技术框架中的一部分，故只要在Windows系统中安装.NET Framework即可。

Windows系统自带.NET Framework

Windows系统默认安装的有.NET Framework，并且可以安装多个.NET Framework版本，你也不需要因此卸载，因为你使用的应用程序可能依赖于特定版本，如果你移除该版本，则应用程序可能会中断。

Microsoft .NET Framework百度百科下有windows系统默认安装的.NET版本 

图出自 https://baike.baidu.com/item/Microsoft%20.NET%20Framework/9926417?fr=aladdin

.NET Framework 4.0.30319

在%SystemRoot%\Microsoft.NET下的Framework和Framework64文件夹中分别可以看到32位和64位的.NET Framework安装的版本。
我们点进去可以看到以.NET版本号为命名的文件夹，有2.0,3.0,3.5,4.0这几个文件夹。

 

.NET Framework4.X覆盖更新

要知道.NET Framework版本目前已经迭代到4.7系列，电脑上明明安装了比4.0更高版本的.NET Framework，然而从文件夹上来看，最高不过4.0，这是为何？
    原来自.NET Framework 4以来的所有.NET Framework版本都是直接在v4.0.30319文件夹上覆盖更新，并且无法安装以前的4.x系列的老版本，所以v4.0.30319这个目录中其实放的是你最后一次更新的NET Framework版本。
.NET Framework覆盖更新：https://docs.microsoft.com/en-us/dotnet/framework/install/guide-for-developers

如何确认本机安装了哪些.NET Framework和对应CLR的版本？

我们可以通过注册表等其它方式来查看安装的最新版本：https://docs.microsoft.com/zh-cn/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed。
不过如果不想那么复杂的话，还有种最直接简单的：
那就是进入该目录文件夹，随便找到几个文件对其右键，然后点击详细信息即可查看到对应的文件版本，可以依据文件版本估摸出.NET Framework版本，比如csc.exe文件。

 

什么是程序集

上文我介绍了编译器，即将源代码文件给翻译成一个计算机可识别的二进制程序。而在.NET Framework目录文件夹中就附带的有 用于C#语言的命令行形式的编译器csc.exe 和 用于VB语言的命令行形式的编译器vbc.exe。

我们通过编译器可以将后缀为.cs(C#)和.vb(VB)类型的文件编译成程序集。
程序集是一个抽象的概念，不同的编译选项会产生不同形式的程序集。以文件个数来区分的话，那么就分 单文件程序集(即一个文件)和多文件程序集(多个文件)。
而不论是单文件程序集还是多文件程序集，其总有一个核心文件，就是表现为后缀为.dll或.exe格式的文件。它们都是标准的PE格式的文件，主要由4部分构成：

  • 1.PE头，即Windows系统上的可移植可执行文件的标准格式
  • 2.CLR头，它是托管模块特有的，它主要包括
    • 1)程序入口方法
    • 2)CLR版本号等一些标志
    • 3)一个可选的强名称数字签名
    • 4)元数据表，主要用来记录了在源代码中定义和引用的所有的类型成员(如方法、字段、属性、参数、事件...)的位置和其标志Flag(各种修饰符) 
            正是因为元数据表的存在，VS才能智能提示，反射才能获取MemberInfo，CLR扫描元数据表即可获得该程序集的相关重要信息，所以元数据表使得程序集拥有了自我描述的这一特性。clr2中，元数据表大概40多个，其核心按照用途分为3类：
      • 1.即用于记录在源代码中所定义的类型的定义表：ModuleDef、TypeDef、MethodDef、ParamDef、FieldDef、PropertyDef、EventDef，
      • 2.引用了其它程序集中的类型成员的引用表：MemberRef、AssemblyRef、ModuleRef、TypeRef
      • 3. 用于描述一些杂项(如版本、发布者、语言文化、多文件程序集中的一些资源文件等)的清单表：AssemblyDef、FileDef、ManifestResourceDef、ExportedTypeDef
  • 3.IL代码(也称MSIL，后来被改名为CIL：Common Intermediate Language通用中间语言)，是介于源代码和本机机器指令中间的代码，将通过CLR在不同的平台产生不同的二进制机器码。
  • 4.一些资源文件

多文件程序集的诞生场景有：比如我想为.exe绑定资源文件(如Icon图标)，或者我想按照功能以增量的方式来按需编译成.dll文件。 通常很少情况下才会将源代码编译成多文件程序集，并且在VS IDE中总是将源代码给编译成单文件的程序集(要么是.dll或.exe)，所以接下来我就以单文件程序集为例来讲解。

用csc.exe进行编译

现在，我将演示一段文本是如何被csc.exe编译成一个可执行的控制台程序的。
我们新建个记事本，然后将下面代码复制上去。

 View Code

然后关闭记事本，将之.txt的后缀改为.cs的后缀(后缀是用来标示这个文件是什么类型的文件，并不影响文件的内容)。

上述代码相当于Web中的http.sys伪实现，是建立了通信的socket服务端，并通过while循环来不断的监视获取包的数据实现最基本的监听功能，最终我们将通过csc.exe将该文本文件编译成一个控制台程序。

我已经在前面讲过BCL，基础类库。在这部分代码中，为了完成我想要的功能，我用到了微软已经帮我们实现好了的String数据类型系列类(.NET下的一些数据类型)、Environment类(提供有关当前环境和平台的信息以及操作它们的方法)、Console类(用于控制台输入输出等)、Socket系列类(对tcp协议抽象的接口)、File文件系列类(对文件目录等操作系统资源的一些操作)、Encoding类(字符流的编码)等
这些类，都属于BCL中的一部分，它们存在但不限于mscorlib.dll、System.dll、System.core.dll、System.Data.dll等这些程序集中。
附：不要纠结BCL到底存在于哪些dll中，总之，它是个物理分散，逻辑上的类库总称。

mscorlib.dll和System.dll的区别：https://stackoverflow.com/questions/402582/mscorlib-dll-system-dll

因为我用了这些类，那么按照编程规则我必须在代码中using这些类的命名空间，并通过csc.exe中的 /r:dll路径 命令来为生成的程序集注册元数据表(即以AssemblyRef为代表的程序集引用表)。
而这些代码引用了4个命名空间，但实际上它们只被包含在mscorlib.dll和System.dll中，那么我只需要在编译的时候注册这两个dll的信息就行了。

好，接下来我将通过cmd运行csc.exe编译器，再输入编译命令： csc /out:D:\demo.exe D:\dic\demo.cs /r:D:\dic\System.dll

/r：是将引用dll中的类型数据注册到程序集中的元数据表中 。
/out:是输出文件的意思，如果没有该命令则默认输出{name}.exe。 
使用csc.exe编译生成： https://docs.microsoft.com/zh-cn/dotnet/csharp/language-reference/compiler-options/command-line-building-with-csc-exe 
csc编译命令行介绍：https://www.cnblogs.com/shuang121/archive/2012/12/24/2830874.html

总之，你除了要掌握基本的编译指令外，当你打上这行命令并按回车后，必须满足几个条件，1.是.cs后缀的c#格式文件，2.是 代码语法等检测分析必须正确，3.是 使用的类库必须有出处(引用的dll)，当然 因为我是编译为控制台程序，所以还必须得有个静态Main方法入口，以上缺一不可。

可以看出，这段命令我是将 位于D:\dic\的demo.cs文件给编译成 位于D:\名为demo.exe的控制台文件，并且因为在代码中使用到了System.dll，所以还需要通过/r注册该元数据表。
这里得注意为什么没有/r:mscorlib.dll,因为mscorlib.dll地位的特殊，所以csc总是对每个程序集进行mscorlib.dll的注册(自包含引用该dll),因此我们可以不用/r:mscorlib.dll这个引用命令，但为了演示效果我还是决定通过/nostdlib命令来禁止csc默认导入mscorlib.dll文件。

所以，最终命令是这样的： csc D:\dic\demo.cs /r:D:\dic\mscorlib.dll /r:D:\dic\System.dll /nostdlib

因为没有指定输出文件/out选项， 所以会默认输出在与csc同一目录下名为demo.exe的文件。事实上，在csc的命令中，如果你没有指定路径，那么就默认采用在csc.exe的所在目录的相对路径。

而我们可以看到，在该目录下有许多程序集，其中就包含我们需要的System.dll和mscorlib.dll，所以我们完全可以直接/r:mscorlib.dll /r:System.dll

而类似于System.dll、System.Data.dll这样使用非常频繁的程序集，我们其实不用每次编译的时候都去手动/r一下，对于需要重复劳动的编译指令，我们可以将其放在后缀为.rsp的指令文件中，然后在编译时直接调用文件即可执行里面的命令 @ {name}.rsp。

csc.exe默认包含csc.rsp文件,我们可以用/noconfig来禁止默认包含，而csc.rsp里面已经写好了我们会经常用到的指令。
所以，最终我可以这样写 csc D:\dic\demo.cs 直接生成控制台应用程序。

.NET程序执行原理

好的，现在我们已经有了一个demo.exe的可执行程序，它是如何被我们运行的？。

C#源码被编译成程序集，程序集内主要是由一些元数据表和IL代码构成，我们双击执行该exe，Windows加载器将该exe(PE格式文件)给映射到虚拟内存中，程序集的相关信息都会被加载至内存中，并查看PE文件的入口点(EntryPoint)并跳转至指定的mscoree.dll中的_CorExeMain函数，该函数会执行一系列相关dll来构造CLR环境，当CLR预热后调用该程序集的入口方法Main()，接下来由CLR来执行托管代码(IL代码)。

JIT编译

前面说了，计算机最终只识别二进制的机器码，在CLR下有一个用来将IL代码转换成机器码的引擎，称为Just In Time Compiler，简称JIT，CLR总是先将IL代码按需通过该引擎编译成机器指令再让CPU执行，在这期间CLR会验证代码和元数据是否类型安全(在对象上只调用正确定义的操作、标识与声称的要求一致、对类型的引用严格符合所引用的类型)，被编译过的代码无需JIT再次编译，而被编译好的机器指令是被存在内存当中，当程序关闭后再打开仍要重新JIT编译。

AOT编译

CLR的内嵌编译器是即时性的，这样的一个很明显的好处就是可以根据当时本机情况生成更有利于本机的优化代码，但同样的，每次在对代码编译时都需要一个预热的操作，它需要一个运行时环境来支持，这之间还是有消耗的。

而与即时编译所对应的，就是提前编译了，英文为Ahead of Time Compilation，简称AOT，也称之为静态编译。
在.NET中，使用Ngen.exe或者开源的.NET Native可以提前将代码编译成本机指令。

Ngen是将IL代码提前给全部编译成本机代码并安装在本机的本机映像缓存中，故而可以减少程序因JIT预热的时间，但同样的也会有很多注意事项，比如因JIT的丧失而带来的一些特性就没有了，如类型验证。Ngen仅是尽可能代码提前编译，程序的运行仍需要完整的CLR来支持。

.NET Native在将IL转换为本机代码的时候，会尝试消除所有元数据将依靠反射和元数据的代码替换为静态本机代码，并且将完整的CLR替换为主要包含垃圾回收器的重构运行时mrt100_app.dll。

.NET Native: https://docs.microsoft.com/zh-cn/dotnet/framework/net-native/ 
Ngen.exe：https://docs.microsoft.com/zh-cn/dotnet/framework/tools/ngen-exe-native-image-generator 
Ngen与.NET Native比较：https://www.zhihu.com/question/27997478/answer/38978762

---------------------------------------------------

现在，我们可以通过ILDASM工具(一款查看程序集IL代码的软件，在Microsoft SDKs目录中的子目录中)来查看该程序集的元数据表和Main方法中间码。

c#源码第一行代码：string rootDirectory = Environment.CurrentDirectory;被翻译成IL代码： call string [mscorlib/*23000001*/]System.Environment/*01000004*/::get_CurrentDirectory() /* 0A000003 */ 

这句话意思是调用 System.Environment类的get_CurrentDirectory()方法(属性会被编译为一个私有字段+对应get/set方法)。

点击视图=>元信息=>显示，即可查看该程序集的元数据。
我们可以看到System.Environment标记值为01000004，在TypeRef类型引用表中找到该项:

注意图，TypeRefName下面有该类型中被引用的成员，其标记值为0A000003，也就是get_CurrentDirectory了。
而从其ResolutionScope指向位于0x23000001而得之，该类型存在于mscorlib程序集。

于是我们打开mscorlib.dll的元数据清单，可以在类型定义表(TypeDef)找到System.Environment,可以从元数据得知该类型的一些标志(Flags,常见的public、sealed、class、abstract)，也得知继承(Extends)于System.Object。在该类型定义下还有类型的相关信息，我们可以在其中找到get_CurrentDirectory方法。 我们可以得到该方法的相关信息，这其中表明了该方法位于0x0002b784这个相对虚地址(RVA)，接着JIT在新地址处理CIL，周而复始。

元数据在运行时的作用： https://docs.microsoft.com/zh-cn/dotnet/standard/metadata-and-self-describing-components#run-time-use-of-metadata

程序集的规则

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

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

程序集的加载方式

对于自身程序集内定义的类型，我们可以直接从自身程序集中的元数据中获取，对于在其它程序集中定义的类型，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属性来添加搜索目录，不过只能填写相对路径： 

<runtime>
            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                <probing privatePath="relative1;relative2;" /> //程序集当前目录下的相对路径目录，用;号分割
            </assemblyBinding>
</runtime>

2.如果程序集是强签名后的，那么可以通过codeBase来指定网络路径或本地绝对路径。

复制代码
<runtime>
            <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
                <dependentAssembly>
                    <assemblyIdentity name="myAssembly"
                                      publicKeyToken="32ab4ba45e0a69a1"
                                      culture="neutral" />
                    <codeBase version="2.0.0.0"
                              href="