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

时间 2019-11-06 标签通俗易懂什么 framework core

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

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

目录github

.NET和C#是什么关系

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

微软公司是全球最大的电脑软件提供商，为了占据开发者市场，进而在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#混为一谈(实质上它们是相辅相成的两个概念)。
而做为一个开发者平台，它不只仅是包含开发环境、技术框架、社区论坛、服务支持等，它还强调了平台的跨语言、跨平台编程的两个特性。 sql

跨语言和跨平台是什么

跨语言：即只要是面向.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中当作自家写的类同样正常使用。c#

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

在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类：
3.IL代码(也称MSIL，后来被更名为CIL：Common Intermediate Language通用中间语言)，是介于源代码和本机机器指令中间的代码，将经过CLR在不一样的平台产生不一样的二进制机器码。
4.一些资源文件

多文件程序集的诞生场景有：好比我想为.exe绑定资源文件(如Icon图标)，或者我想按照功能以增量的方式来按需编译成.dll文件。一般不多状况下才会将源代码编译成多文件程序集，而且在VS IDE中老是将源代码给编译成单文件的程序集(要么是.dll或.exe)，因此接下来我就以单文件程序集为例来说解。

用csc.exe进行编译

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

    using System;
    using System.IO;
    using System.Net.Sockets;
    using System.Text;
    class Program
    {
        static void Main()
        {
            string rootDirectory = Environment.CurrentDirectory;
            Console.WriteLine("开始链接，端口号：8090");
            Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
            socket.Bind(new System.Net.IPEndPoint(System.Net.IPAddress.Loopback, 8090));
            socket.Listen(30);
            while (true)
            {
                Socket socketClient = socket.Accept();
                Console.WriteLine("新请求");
                byte[] buffer = new byte[4096];
                int length = socketClient.Receive(buffer, 4096, SocketFlags.None);
                string requestStr = Encoding.UTF8.GetString(buffer, 0, length);
                Console.WriteLine(requestStr);
                //
                string[] strs = requestStr.Split(new string[] { "\r\n" }, StringSplitOptions.None);
                string url = strs[0].Split(' ')[1];

                byte[] statusBytes, headerBytes, bodyBytes;

                if (Path.GetExtension(url) == ".jpg")
                {
                    string status = "HTTP/1.1 200 OK\r\n";
                    statusBytes = Encoding.UTF8.GetBytes(status);
                    bodyBytes = File.ReadAllBytes(rootDirectory + url);
                    string header = string.Format("Content-Type:image/jpg;\r\ncharset=UTF-8\r\nContent-Length:{0}\r\n", bodyBytes.Length);
                    headerBytes = Encoding.UTF8.GetBytes(header);
                }
                else
                {
                    if (url == "/")
                        url = "默认页";
                    string status = "HTTP/1.1 200 OK\r\n";
                    statusBytes = Encoding.UTF8.GetBytes(status);
                    string body = "<html>" +
                        "<head>" +
                            "<title>socket webServer  -- Login</title>" +
                        "</head>" +
                        "<body>" +
                           "<div style=\"text-align:center\">" +
                               "当前访问" + url +
                           "</div>" +
                        "</body>" +
                    "</html>";
                    bodyBytes = Encoding.UTF8.GetBytes(body);
                    string header = string.Format("Content-Type:text/html;charset=UTF-8\r\nContent-Length:{0}\r\n", bodyBytes.Length);
                    headerBytes = Encoding.UTF8.GetBytes(header);
                }
                socketClient.Send(statusBytes);
                socketClient.Send(headerBytes);
                socketClient.Send(new byte[] { (byte)'\r', (byte)'\n' });
                socketClient.Send(bodyBytes);

                socketClient.Close();
            }
        }
    }

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="http://www.litwareinc.com/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，就会报：发现同一依赖程序集的不一样版本间存在没法解决的冲突这一警告。

 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版本

<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>

View Code

如何在编译时加载两个相同的程序集？

注意：我看过有的文章里写的一个AppDomain只能加载一个相同的程序集，不少人都觉得不能同时加载2个不一样版本的程序集，实际上CLR是能够同时加载Newtonsoft.Json 6.0和Newtonsoft.Json 10.0的。

第二种：对每一个版本指定codeBase路径，而后分别放上不一样版本的程序集，这样就能够加载两个相同的程序集。

<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>

View Code

如何同时调用两个两个相同命名空间和类型的程序集？

除了程序集版本不一样外，还有一种状况就是，我一个项目同时引用了程序集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被加载在哪里？内存堆中又是什么样的一个状况？

应用程序域

传统非托管程序是直接承载在Windows进程中，托管程序是承载在.NET虚拟机CLR上的，而在CLR中管控的这部分资源中，被分红了一个个逻辑上的分区，这个逻辑分区被称为应用程序域，是.NET Framework中定义的一个概念。
由于堆内存的构建和删除都经过GC去托管，下降了人为出错的概率，在此特性基础上.NET强调在一个进程中经过CLR强大的管理创建起对资源逻辑上的隔离区域，每一个区域的应用程序互不影响，从而让托管代码程序的安全性和健壮性获得了提高。

熟悉程序集加载规则和AppDomain是在.NET技术下进行插件编程的前提。AppDomain这部分概念并不复杂。
当启动一个托管程序时，最早启动的是CLR，在这过程当中会经过代码初始化三个逻辑区域，最早是SystemDomain系统程序域，而后是SharedDoamin共享域，最后是{程序集名称}Domain默认域。

系统程序域里维持着一些系统构建项，咱们能够经过这些项来监控并管理其它应用程序域等。共享域存放着其它域都会访问到的一些信息，当共享域初始化完毕后，会自动加载mscorlib.dll程序集至该共享域。而默认域则用储存自身程序集的信息，咱们的主程序集就会被加载至这个默认域中，执行程序入口方法，在没有特殊动做外所产生的一切耗费都发生在该域。

咱们能够在代码中建立和卸载应用程序域，域与域之间有隔离性，挂掉A域不会影响到B域，而且对于每个加载的程序集都要指定域的，没有在代码中指定域的话，默认都是加载至默认域中。
AppDomain能够想象成组的概念，AppDomain包含了咱们加载的一组程序集。咱们经过代码卸载AppDomain，即同时卸载了该AppDomain中所加载的全部程序集在内存中的相关区域。

AppDomain的初衷是边缘隔离，它可让程序不从新启动而长时间运行，围绕着该概念创建的体系从而让咱们可以使用.NET技术进行插件编程。

当咱们想让程序在不关闭不从新部署的状况下添加一个新的功能或者改变某一块功能，咱们能够这样作：将程序的主模块仍默认加载至默认域，再建立一个新的应用程序域，而后将须要更改或替换的模块的程序集加载至该域，每当更改和替换的时候直接卸载该域便可。而由于域的隔离性，我在A域和B域加载同一个程序集，那么A域和B域就会各存在内存地址不一样但数据相同的程序集数据。

跨边界访问

事实上，在开发中咱们还应该注意跨域访问对象的操做(即在A域中的程序集代码直接调用B域中的对象)是与日常编程中有所不一样的，一个域中的应用程序不能直接访问另外一个域中的代码和数据，对于这样的在进程内跨域访问操做分两类。

一是按引用封送，须要继承System.MarshalByRefObject，传递的是该对象的代理引用，与源域有相同的生命周期。
二是按值封送，须要被[Serializable]标记，是经过序列化传递的副本，副本与源域的对象无关。
不管哪一种方式都涉及到两个域直接的封送、解封，因此跨域访问调用不适用于太高频率。
(好比，原来你是这样调用对象： var user=new User(); 如今你要这样：var user=(User){应用程序域对象实例}.CreateInstanceFromAndUnwrap("Model.dll","Model.User"); )

值得注意的是，应用程序域是对程序集的组的划分，它与进程中的线程是两个一横一竖，方向不同的概念，不该该将这2个概念放在一块儿比较。咱们能够经过Thread.GetDomain来查看执行线程所在的域。
应用程序域在类库中是System.AppDomain类,部分重要的成员有：

        获取当前 System.Threading.Thread 的当前应用程序域
        public static AppDomain CurrentDomain { get; }
        使用指定的名称新建应用程序域
        public static AppDomain CreateDomain(string friendlyName);
        卸载指定的应用程序域。
        public static void Unload(AppDomain domain);
        指示是否对当前进程启用应用程序域的 CPU 和内存监视，开启后能够根据相关属性进行监控
        public static bool MonitoringIsEnabled { get; set; }
        当前域托管代码抛出异常时最早发生的一个事件，框架设计中能够用到
        public event EventHandler<FirstChanceExceptionEventArgs> FirstChanceException;
        当某个异常未被捕获时调用该事件，如代码里只catch了a异常，实际产生的是 b异常，那么b异常就没有捕捉到。
        public event UnhandledExceptionEventHandler UnhandledException;
        为指定的应用程序域属性分配指定值。该应用程序域的局部存储值，该存储不划分上下文和线程，都可经过GetData获取。
        public void SetData(string name, object data);
        若是想使用托管代码来覆盖CLR的默认行为https://msdn.microsoft.com/zh-cn/library/system.appdomainmanager(v=vs.85).aspx
        public AppDomainManager DomainManager { get; }
        返回域的配置信息，如在config中配置的节点信息
        public AppDomainSetup SetupInformation { get; }

应用程序域： https://docs.microsoft.com/zh-cn/dotnet/framework/app-domains/application-domains

AppDomain和AppPool

注意：此处的AppDomain应用程序域和 IIS中的AppPool应用程序池是2个概念，AppPool是IIS独有的概念，它也至关于一个组的概念，对网站进行划组，而后对组进行一些如进程模型、CPU、内存、请求队列的高级配置。

内存

应用程序域把资源给隔离开，这个资源，主要指内存。那么什么是内存呢？

要知道，程序运行的过程就是电脑不断经过CPU进行计算的过程，这个过程须要读取并产生运算的数据，为此咱们须要一个拥有足够容量可以快速与CPU交互的存储容器，这就是内存了。对于内存大小，32位处理器，寻址空间最大为2的32次方byte，也就是4G内存，除去操做系统所占用的公有部分，进程大概能占用2G内存，而若是是64位处理器，则是8T。

而在.NET中，内存区域分为堆栈和托管堆。

堆栈和堆的区别

堆和堆栈就内存而言只不过是地址范围的区别。不过堆栈的数据结构和其存储定义让其在时间和空间上都紧密的存储，这样能带来更高的内存密度，能在CPU缓存和分页系统表现的更好。故而访问堆栈的速度整体来讲比访问堆要快点。

线程堆栈

操做系统会为每条线程分配必定的空间，Windwos为1M，这称之为线程堆栈。在CLR中的栈主要用来执行线程方法时，保存临时的局部变量和函数所需的参数及返回的值等，在栈上的成员不受GC管理器的控制，它们由操做系统负责分配，当线程走出方法后，该栈上成员采用后进先出的顺序由操做系统负责释放，执行效率高。
而托管堆则没有固定容量限制，它取决于操做系统容许进程分配的内存大小和程序自己对内存的使用状况，托管堆主要用来存放对象实例，不须要咱们人工去分配和释放，其由GC管理器托管。

为何值类型存储在栈上

不一样的类型拥有不一样的编译时规则和运行时内存分配行为，咱们应知道，C# 是一种强类型语言，每一个变量和常量都有一个类型，在.NET中，每种类型又被定义为值类型或引用类型。

使用 struct、enum 关键字直接派生于System.ValueType定义的类型是值类型，使用 class、interface、delagate 关键字派生于System.Object定义的类型是引用类型。
对于在一个方法中产生的值类型成员，将其值分配在栈中。这样作的缘由是由于值类型的值其占用固定内存的大小。

C#中int关键字对应BCL中的Int32，short对应Int16。Int32为2的32位，若是把32个二进制数排列开来，咱们要求既能表达正数也能表达负数，因此得须要其中1位来表达正负，首位是0则为+，首位是1则为-，那么咱们能表示数据的数就只有31位了，而0是介于-1和1之间的整数，因此对应的Int32能表现的就是2的31次方到2的31次方-1，即2147483647和-2147483648这个整数段。

1个字节=8位，32位就是4个字节，像这种以Int32为表明的值类型，自己就是固定的内存占用大小，因此将值类型放在内存连续分配的栈中。

托管堆模型

而引用类型相比值类型就有点特殊，newobj建立一个引用类型，因其类型内的引用对象能够指向任何类型，故而没法准确得知其固定大小，因此像对于引用类型这种没法预知的容易产生内存碎片的动态内存，咱们把它放到托管堆中存储。

托管堆由GC托管，其分配的核心在于堆中维护着一个nextObjPtr指针，咱们每次实例(new)一个对象的时候，CLR将对象存入堆中，并在栈中存放该对象的起始地址，而后该指针都会根据该对象的大小来计算下一个对象的起始地址。不一样于值类型直接在栈中存放值，引用类型则还须要在栈中存放一个表明(指向)堆中对象的值(地址)。

而托管堆又能够因存储规则的不一样将其分类，托管堆能够被分为3类：

1.用于托管对象实例化的垃圾回收堆，又以存储对象大小分为小对象(<85000byte)的GC堆(SOH，Small Object Heap)和用于存储大对象实例的(>=85000byte)大对象堆(LOG，Larage Object Heap)。
2.用于存储CLR组件和类型系统的加载(Loader)堆，其中又以使用频率分为常常访问的高频堆(里面包含有MethodTables方法表, MeghodDescs方法描述, FieldDescs方法描述和InterfaceMaps接口图)，和较低的低频堆，和Stub堆(辅助代码，如JIT编译后修改机器代码指令地址环节)。
3.用于存储JIT代码的堆及其它杂项的堆。

加载程序集就是将程序集中的信息给映射在加载堆，对产生的实例对象存放至垃圾回收堆。前文说过应用程序域是指经过CLR管理而创建起的逻辑上的内存边界，那么每一个域都有其本身的加载堆，只有卸载应用程序域的时候，才会回收该域对应的加载堆。

而加载堆中的高频堆包含的有一个很是重要的数据结构表---方法表，每一个类型都仅有一份方法表(MethodTables)，它是对象的第一个实例建立前的类加载活动的结果，它主要包含了咱们所关注的3部分信息：

1包含指向EEClass的一个指针。EEClass是一个很是重要的数据结构，当类加载器加载到该类型时会从元数据中建立出EEClass，EEClass里主要存放着与类型相关的表达信息。
2包含指向各自方法的方法描述器(MethodDesc)的指针逻辑组成的线性表信息:继承的虚函数, 新虚函数, 实例方法, 静态方法。
3包含指向静态字段的指针。

那么，实例一个对象，CLR是如何将该对象所对应的类型行为及信息的内存位置(加载堆)关联起来的呢？

原来，在托管堆上的每一个对象都有2个额外的供于CLR使用的成员，咱们是访问不到的，其中一个就是类型对象指针，它指向位于加载堆中的方法表从而让类型的状态和行为关联了起来，类型指针的这部分概念咱们能够想象成obj.GetType()方法得到的运行时对象类型的实例。而另外一个成员就是同步块索引，其主要用于2点：1.关联内置SyncBlock数组的项从而完成互斥锁等目的。 2.是对象Hash值计算的输入参数之一。

上述gif是我简单画的一个图，能够看到对于方法中申明的值类型变量，其在栈中做为一块值表示，咱们能够直接经过c#运算符sizeof来得到值类型所占byte大小。而方法中申明的引用类型变量，其在托管堆中存放着对象实例(对象实例至少会包含上述两个固定成员以及实例数据，可能)，在栈中存放着指向该实例的地址。

当我new一个引用对象的时候，会先分配同步块索引(也叫对象头字节)，而后是类型指针，最后是类型实例数据(静态字段的指针存在于方法表中)。会先分配对象的字段成员，而后分配对象父类的字段成员，接着再执行父类的构造函数，最后才是本对象的构造函数。这个多态的过程，对于CLR来讲就是一系列指令的集合，因此不能纠结new一个子类对象是否会也会new一个父类对象这样的问题。而也正是由于引用类型的这样一个特征，咱们虽然能够估计一个实例大概占用多少内存，但对于具体占用的大小，咱们须要专门的工具来测量。

对于引用类型，u2=u1，咱们在赋值的时候，实际上赋的是地址，那么我改动数据其实是改动该地址指向的数据，这样一来，由于u2和u1都指向同一块区域，因此我对u1的改动会影响到u2，对u2的改动会影响到u1。若是我想互不影响，那么我能够继承IClone接口来实现内存克隆，已有的CLR实现是浅克隆方法，但也只能克隆值类型和String(string是个特殊的引用类型，对于string的更改，其会产生一个新实例对象)，若是对包含其它引用类型的这部分，咱们能够本身经过其它手段实现深克隆，如序列化、反射等方式来完成。而若是引用类型中包含有值类型字段，那么该字段仍然分配在堆上。

对于值类型，a=b，咱们在赋值的时候，其实是新建了个值，那么我改动a的值那就只会改动a的值，改动b的值就只会改动b的值。而若是值类型(如struct)中包含的有引用类型，那么还是一样的规则，引用类型的那部分实例在托管堆中，地址在栈上。

我若是将值类型放到引用类型中(如：object a=3)，会在栈中生成一个地址，在堆中生成该值类型的值对象，还会再生成这类型指针和同步块索引两个字段，这也就是常说装箱，反过来就是拆箱。每一次的这样的操做，都会涉及到内存的分布、拷贝，可见，装箱和拆箱是有性能损耗，所以应该减小值类型和引用类型之间转换的次数。
但对于引用类型间的子类父类的转换，仅是指令的执行消耗，几尽没有开销。

选class仍是struct

那么我究竟是该new一个class呢仍是选择struct呢？

经过上文知道对于class，用完以后对象仍然存在托管堆，占用内存。对于struct，用完以后直接由操做系统销毁。那么在实际开发中定义类型时，选择class仍是struct就须要注意了，要综合应用场景来辨别。struct存在于栈上，栈和托管堆比较，最大的优点就是即用即毁。因此若是咱们单纯的传递一个类型，那么选择struct比较合适。但须注意线程堆栈有容量限制，不可多存放超大量的值类型对象，而且由于是值类型直接传递副本，因此struct做为方法参数是线程安全的，但一样要避免装箱的操做。而相比较class，若是类型中还须要多一些封装继承多态的行为，那么class固然是更好的选择。

GC管理器

值得注意的是，当我new完一个对象再也不使用的时候，这个对象在堆中所占用的内存如何处理？
在非托管世界中，能够经过代码手动进行释放，但在.NET中，堆彻底由CLR托管，也就是说GC堆是如何具体来释放的呢？

当GC堆须要进行清理的时候，GC收集器就会经过必定的算法来清理堆中的对象，而且版本不一样算法也不一样。最主要的则为Mark-Compact标记-压缩算法。
这个算法的大概含义就是，经过一个图的数据结构来收集对象的根，这个根就是引用地址，能够理解为指向托管堆的这根关系线。当触发这个算法时，会检查图中的每一个根是否可达，若是可达就对其标记，而后在堆上找到剩余没有标记(也就是不可达)的对象进行删除，这样，那些不在使用的堆中对象就删除了。

前面说了，由于nextObjPtr的缘故，在堆中分配的对象都是连续分配的，由于未被标记而被删除，那么通过删除后的堆就会显得支零破碎，那么为了不空间碎片化，因此须要一个操做来让堆中的对象再变得紧凑、连续，而这样一个操做就叫作：Compact压缩。
而对堆中的分散的对象进行挪动后，还会修改这些被挪动对象的指向地址，从而得以正确的访问，最后从新更新一下nextObjPtr指针，周而复始。

而为了优化内存结构，减小在图中搜索的成本，GC机制又为每一个托管堆对象定义了一个属性，将每一个对象分红了3个等级，这个属性就叫作：代，0代、1代、2代。

每当new一个对象的时候，该对象都会被定义为第0代，当GC开始回收的时候，先从0代回收，在这一次回收动做以后，0代中没有被回收的对象则会被定义成第1代。当回收第1代的时候，第1代中没有被清理掉的对象就会被定义到第2代。
CLR初始化时会为0/1/2这三代选择一个预算的容量。0代一般以256 KB-4 MB之间的预算开始，1代的典型起始预算为512 KB-4 MB，2代不受限制，最大可扩展至操做系统进程的整个内存空间。

好比第0代为256K，第1代为2MB。咱们不停的new对象，直到这些对象达到256k的时候，GC会进行一次垃圾回收，假设此次回收中回收了156k的不可达对象，剩余100k的对象没有被回收，那么这100k的对象就被定义为第1代。如今就变成了第0代里面什么都没有，第1代里放的有100k的对象。这样周而复始，GC清除的永远都只有第0代对象，除非当第一代中的对象累积达到了定义的2MB的时候，才会连同清理第1代，而后第1代中活着的部分再升级成第二代...

第二代的容量是没有限制，可是它有动态的阈值(由于等到整个内存空间已满以执行垃圾回收是没有意义的)，当达到第二代的阈值后会触发一次0/1/2代完整的垃圾收集。

也就是说，代数越长说明这个对象经历了回收的次数也就越多，那么也就意味着该对象是不容易被清除的。
这种分代的思想来将对象分割成新老对象，进而配对不一样的清除条件，这种巧妙的思想避免了直接清理整个堆的尴尬。

弱引用、弱事件

GC收集器会在第0代饱和时开始回收托管堆对象，对于那些已经申明或绑定的不经访问的对象或事件，由于不常常访问并且还占内存(有点懒加载的意思)，因此即时对象可达，但我想在GC回收的时候仍然对其回收，当须要用到的时候再建立，这种状况该怎么办？

那么这其中就引入了两个概念：
WeakReference弱引用、WeakEventManager弱事件
对于这2两个不区分语言的共同概念，你们可自行扩展百度，此处就再也不举例。

GC堆回收

那么除了经过new对象而达到代的阈(临界)值时，还有什么可以致使垃圾堆进行垃圾回收呢？还可能windows报告内存不足、CLR卸载AppDomain、CLR关闭等其它特殊状况。

或者，咱们还能够本身经过代码调用。

.NET有GC来帮助开发人员管理内存，而且版本也在不断迭代。GC帮咱们托管内存，但仍然提供了System.GC类让开发人员可以轻微的协助管理。这其中有一个能够清理内存的方法(并无提供清理某个对象的方法)：GC.Collect方法，能够对全部或指定代进行即时垃圾回收(若是想调试，需在release模式下才有效果)。这个方法尽可能别用，由于它会扰乱代与代间的秩序，从而让低代的垃圾对象跑到生命周期长的高代中。

GC还提供了，判断当前对象所处代数、判断指定代数经历了多少次垃圾回收、获取已在托管堆中分配的字节数这样的三个方法，咱们能够从这3个方法简单的了解托管堆的状况。

托管世界的内存不须要咱们打理，咱们没法从代码中得知具体的托管对象的大小，你若是想追求对内存最细微的控制，显然C#并不适合你，不过相似于有关内存把控的这部分功能模块，咱们能够经过非托管语言来编写，而后经过.NET平台的P/Invoke或COM技术(微软为CLR定义了COM接口并在注册表中注册)来调用。

像FCL中的源码，不少涉及到操做系统的诸如文件句柄、网络链接等外部extren的底层方法都是非托管语言编写的，对于这些非托管模块所占用的资源，咱们能够经过隐式调用析构函数(Finalize)或者显式调用的Dispose方法经过在方法内部写上非托管提供的释放方法来进行释放。

像文中示例的socket就将释放资源的方法写入Dispose中，析构函数和Close方法均调用Dispose方法以此完成释放。事实上，在FCL中的使用了非托管资源的类大多都遵循IDispose模式。而若是你没有释放非托管资源直接退出程序，那么操做系统会帮你释放该程序所占的内存的。

垃圾回收对性能的影响

还有一点，垃圾回收是对性能有影响的。
GC虽然有不少优化策略，但总之，只要当它开始回收垃圾的时候，为了防止线程在CLR检查期间对对象更改状态，因此CLR会暂停进程中的几乎全部线程(因此线程太多也会影响GC时间)，而暂停的时间就是应用程序卡死的时间，为此，对于具体的处理细节，GC提供了2种配置模式让咱们选择。

第一种为：单CPU的工做站模式，专为单CPU处理器定作。这种模式会采用一系列策略来尽量减小GC回收中的暂停时间。
而工做站模式又分为并发(或后台)与不并发两种，并发模式表现为响应时间快速，不并发模式表现为高吞吐量。

第二种为：多CPU的服务器模式，它会为每一个CPU都运行一个GC回收线程，经过并行算法来使线程能真正同时工做，从而得到性能的提高。

咱们能够经过在Config文件中更改配置来修改GC模式，若是没有进行配置，那么应用程序老是默认为单CPU的工做站的并发模式，而且若是机器为单CPU的话，那么配置服务器模式则无效。

若是在工做站模式中想禁用并发模式，则应该在config中运行时节点添加 <gcConcurrent enabled="false" />
若是想更改至服务器模式，则能够添加 <gcServer enabled="true" />。

 <configuration>
        <runtime>
            <!--<gcConcurrent enabled="true|false"/>-->
            <!--<gcServer enabled="true|false"/>-->
        </runtime>
</configuration>

gcConcurrent: https://docs.microsoft.com/zh-cn/dotnet/framework/configure-apps/file-schema/runtime/gcconcurrent-element
gcServer: https://docs.microsoft.com/zh-cn/dotnet/framework/configure-apps/file-schema/runtime/gcserver-element

性能建议

虽然咱们能够选择适合的GC工做模式来改善垃圾回收时的表现，但在实际开发中咱们更应该注意减小没必要要的内存开销。

几个建议是，减换须要建立大量的临时变量的模式、考虑对象池、大对象使用懒加载、对固定容量的集合指定长度、注意字符串操做、注意高频率的隐式装箱操做、延迟查询、对于不须要面向对象特性的类用static、须要高性能操做的算法改用外部组件实现(p/invoke、com)、减小throw次数、注意匿名函数捕获的外部对象将延长生命周期、能够阅读GC相关运行时配置在高并发场景注意变换GC模式...

对于.NET中改善性能可延伸阅读 https://msdn.microsoft.com/zh-cn/library/ms973838.aspx 、 https://msdn.microsoft.com/library/ms973839.aspx

.NET程序执行图

至此，.NET Framework上的三个重要概念，程序集、应用程序域、内存在本文讲的差很少了，我画了一张图简单的概述.NET程序的一个执行流程：

对于后文，我将单独的介绍一些其它杂项，首先是.NET平台的安全性。

.NET的安全性

.NET Framework中的安全机制分为基于角色的安全机制和代码访问安全机制。

基于角色的安全性

基于角色的安全机制做为传统的访问控制，其运用的很是普遍，如操做系统的安全策略、数据库的安全策略等等...它的概念就至关于咱们常常作的那些RBAC权限管理系统同样，用户关联角色，角色关联权限，权限对应着操做。
整个机制的安全逻辑就和咱们平时编写代码判断是同样的，大体能够分为两个步骤.

第一步就是建立一个主体，而后标识这个主体是什么身份(角色) ，第二步就是身份验证，也就是if判断该身份是否能够这样操做。

而在.NET Framework中，这主体能够是Windows帐户，也能够是自定义的标识，经过生成如当前线程或应用程序域使用的主体相关的信息来支持受权。
好比，构造一个表明当前登陆帐户的主体对象WindowsPrincipal，而后经过 AppDomain.CurrentDomain.SetThreadPrincipal(主体对象);或Thread.CurrentPrincipal的set方法来设置应用程序域或线程的主体对象，最后使用System.Security.Permissions.PrincipalPermission特性来标记在方法上来进行受权验证。

如图，我当前登陆帐号名称为DemoXiaoZeng，而后经过Thread.CurrentPrincipal设置当前主体，执行aa方法，顺利打印111。若是检测到PrincipalPermission类中的Name属性值不是当前登陆帐号，那么就报错：对主体权限请求失败。

在官方文档中有对.NET Framework基于角色的安全性的详细的介绍，感兴趣能够去了解 https://docs.microsoft.com/zh-cn/dotnet/standard/security/principal-and-identity-objects#principal-objects

代码访问安全性

在.NET Framework中还有一个安全策略，叫作代码访问安全Code Access Security，也就是CAS了。

代码访问安全性在.NET Framework中是用来帮助限制代码对受保护资源和操做的访问权限。
举个例子，我经过建立一个FileIOPermission对象来限制对后续代码对D盘的文件和目录的访问，若是后续代码对D盘进行资源操做则报错。

FileIOPermission是代码控制访问文件和文件夹的能力。除了FileIOPermission外，还有如PrintingPermission代码控制访问打印机的权限、RegistryPermission代码控制操做注册表的权限、SocketPermission控制接受链接或启动Socket链接的权限。

对于这些经过代码来对受保护资源和操做的权限限制，也就是这些类名后缀为Permission的类，它们叫作 Permissions(权限)，都继承自CodeAccessPermission，都有如Demand，Assert，Deny，PermitOnly，IsSubsetOf，Intersect和Union这些方法，在MSDN上有完整的权限列表：https://msdn.microsoft.com/en-us/library/h846e9b3(v=vs.100).aspx

为了肯定代码是否有权访问某一资源或执行某一操做，CLR的安全系统将审核调用堆栈，以将每一个调用方得到的权限与要求的权限进行比较。若是调用堆栈中的任何调用方不具有要求的权限，则会引起安全性异常并拒绝访问。

图出自 https://docs.microsoft.com/zh-cn/dotnet/framework/misc/code-access-security

而除了Permissions权限，代码访问安全性机制还有权限集、证据、代码组、策略等概念。这些概念让CAS如此强大，但相应的，它们也让CAS变得复杂，必须为每一个特定机器定义正确的PermissionSet和Code Groups才能设置成一个成功的CAS策略。

考虑到这层缘由，Microsoft .NET安全小组决定从头开始重建代码访问安全性。在.NET Framework4.0以后，就再也不使用以前的那套CAS模型了，而是使用.NET Framework 2.0中引入的安全透明模型，而后稍加修改，修改后的安全透明模型成为保护资源的标准方法，被称之为：安全透明度级别2

安全透明度2介绍：https://msdn.microsoft.com/en-us/library/dd233102(v=vs.100).aspx
.NET Framework4.0的安全更改：https://msdn.microsoft.com/en-us/library/dd233103(v=vs.100).aspx
一个完整的CAS演示：https://www.codeproject.com/Articles/5724/Understanding-NET-Code-Access-Security

对于安全透明度级别2我将再也不介绍，感兴趣的能够看我推荐的这2篇文章，对Level2的安全透明度介绍的比较详细，包括实践、迁移。
https://www.red-gate.com/simple-talk/dotnet/.net-framework/whats-new-in-code-access-security-in-.net-framework-4.0---part-i/
https://www.red-gate.com/simple-talk/dotnet/net-framework/whats-new-in-code-access-security-in-net-framework-4-0-part-2/

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

须注意：
.NET平台上的安全机制，仅仅是.NET平台上的，所以它只限制于托管代码，咱们能够直接调用非托管代码或进程通讯间接调用非托管代码等多个手段来突破对托管代码操做资源的限制。

事实上，咱们在日常项目中代码编写的安全机制(业务逻辑身份验证、项目框架验证)与这些平台级的安全机制没什么不一样。咱们能够理解为代码写的位置不同，.NET安全机制是写在CLR组件中，而咱们的安全机制是写在上层的代码中。这些平台级的标识更多的是和操做系统用户有关，而咱们项目代码中的标识则是和在数据库中注册的用户有关，你们都是经过if else来去判断，判断的主体和格局不同，逻辑本质都是相同的。

NET Core不支持代码访问安全性和安全性透明性。

.NET是什么

我在前文对.NET系统概述时，有的直接称.NET，有的称.NET Framework。那么准确来讲什么是.NET?什么又是.NET Framework呢？

.NET是一个微软搭造的开发者平台，它主要包括：

1.支持(面向)该平台的编程语言(如C#、Visual Basic、C++/CLI、F#、IronPython、IronRuby...)，
2.用于该平台下开发人员的技术框架体系(.NET Framework、.NET Core、Mono、UWP等)，

1.定义了通用类型系统，庞大的CTS体系
2.用于支撑.NET下的语言运行时的环境：CLR
3..NET体系技术的框架库FCL

3.用于支持开发人员开发的软件工具(即SDK，如VS201七、VS Code等)

.NET Framework是什么

事实上，像我上面讲的那些诸如程序集、GC、AppDomain这样的为CLR的一些概念组成，实质上指的是.NET Framework CLR。

.NET平台是微软为了占据开发市场而成立的，不是无利益驱动的纯技术平台的那种东西。基于该平台下的技术框架也由于商业间的利益从而和微软自身的Windows操做系统所绑定。因此虽然平台雄心和口号很大，但不少框架类库技术都是以Windows系统为蓝本，这样就致使，虽然.NET各方面都挺好，可是用.NET就必须用微软的东西，直接造成了技术-商业的绑定。

.NET Framework就是.NET 技术框架组成在Windows系统下的具体的实现，和Windows系统高度耦合，上文介绍的.NET系统，就是指.NET Framework。

部署.net Framework ：https://docs.microsoft.com/zh-cn/dotnet/framework/deployment/deployment-guide-for-developers
.NET Framework高级开发：https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/29eafad8(v%3dvs.90)
.NET Framework源码在线浏览：https://referencesource.microsoft.com/

如何在VS中调试.NET Framework源代码

最为关键的是pdb符号文件，没得符号就调不了，对于符号咱们从微软的符号服务器上下载(默认就已配置)，还得有源代码来调试。

点击工具-选项-调试-常规，若是你以前没有在该配置栏配置过，那么你就勾选启用源服务器支持、启用.net Framework源代码单步执行，而后将要求源文件与原始版本彻底匹配给取消掉。

而后就是下载pdb符号文件了，若是想直接下载那么能够在调试-符号这栏将Microsoft符号服务器给勾上。若是想按需下载，那么在调试的时候，能够点击调试-窗口选择模块/调用堆栈来选择本身想加载的去加载。

而后至 https://referencesource.microsoft.com/网站点击右上角下载源代码。当你调试代码的时候，会提示你无可用源，这个时候你再将你下载下来的源码文件给浏览查找一下就能够了。

如何配置VS来调试.NET Framework源码： https://referencesource.microsoft.com/#q=web 、 https://technet.microsoft.com/zh-cn/cc667410.aspx

还一种方法是，下载.NET Reflector插件，该插件能够帮助咱们在VS中直接调试dll，这种方式操做很是简单，不过该插件收费，具体的能够查看我以前写过的文章(群里有该插件的注册版)

.NET Core是什么

有丑才有美，有低才有高，概念是比较中诞生的。.NET Core就是如此，它是其它操做系统的.NET Framework翻版实现。

操做系统不止Windows，还有Mac和类Linux等系统， .NET的实现若是按操做系统来横向分割的话，能够分为 Windows系统下的 .NET Framework 和兼容多个操做系统的 .NET Core。

咱们知道，一个.NET程序运行核心在于.NET CLR，为了能让.NET程序在其它平台上运行，一些非官方社区和组织为此开发了在其它平台下的.NET实现（最为表明的是mono，其团队后来又被微软给合并了），但由于不是官方，因此在一些方面多少有些缺陷(如FCL)，后来微软官方推出了.NET Core，其开源在Github中，并被收录在NET基金会(.NET Foundation，由微软公司成立与赞助的独立自由软件组织，其目前收录包括.NET编译器平台("Roslyn")以及ASP.NET项目系列，.NET Core，Xamarin Forms以及其它流行的.NET开源框架)，旨在真正的 .NET跨平台。

.NET Core是.NET 技术框架组成在Windows.macOS.Linux系统下的具体的实现。
.NET Core是一个开源的项目，其由 Microsoft 和 GitHub 上的 .NET 社区共同维护，但这份工做仍然是巨大的，由于在早期对.NET上的定义及最初的实现一直是以Windows系统为参照及载体，一些.NET机制实际上与Windows系统耦合度很是高，有些属于.NET本身体系内的概念，有些则属于Windows系统api的封装。那么从Windows转到其它平台上，不只要实现相应的CLR，还要舍弃或重写一部分BCL，于是，.NET Core在概念和在项目中的行为与咱们日常有些不一样。

好比，NET Core不支持AppDomains、远程处理、代码访问安全性 (CAS) 和安全透明度，任何有关该概念的库代码都应该被替换。
这部分代码它不只指你项目中的代码，还指你项目中using的那些程序集代码，因此你会在github上看到不少开源项目都在跟进对.NET Core的支持,而且不少开发者也尝试学习.NET Core，这也是一种趋势。

.NET Core指南https://docs.microsoft.com/en-us/dotnet/core/
.NET基金会：https://dotnetfoundation.org
.NET Core跨平台的行为变动：https://github.com/dotnet/corefx/wiki/ApiCompat
微软宣布.NET开发环境将开源：https://news.cnblogs.com/n/508410/

.NET Standard是什么

值得一提的是微软还为BCL提出了一个标准，毕竟各式各样的平台，技术层出不穷，为了防止.NET在类库方面的碎片化，即提出了一套正式的 .NET API (.NET 的应用程序编程接口)规范，.NET Standard。

正如上面CLS同样，.NET Standard就相似于这样的一个概念，不管是哪一个托管框架，咱们遵循这个标准，就能始终保持在BCL的统一性，即我不须要关心我是用的.NET Framework仍是.NET Core，只要该类被定义于.NET Standard中，我就必定能在对应支持的.NET Standard的版本的托管框架中找到它。

.NET Standard： https://docs.microsoft.com/zh-cn/dotnet/standard/net-standard#net-implementation-support

.NET Standard开源代码：https://github.com/dotnet/standard

.NET官方开源项目连接

如今我将给出.NET相关的开源项目地址：
参与.NET和.NET开源项目的起点：https://github.com/Microsoft/dotnet

.NET Core：https://github.com/dotnet/core
.NET Core文档：https://github.com/dotnet/docs
ASP.NET Core：https://github.com/aspnet/home
ASP.NET Core文档：https://github.com/aspnet/Docs
EntityFramework Core框架:https://github.com/aspnet/EntityFrameworkCore
ASP.NET Core MVC框架：https://github.com/aspnet/Mvc
EntityFramework6:https://github.com/aspnet/EntityFramework6
.NET Framework源码：https://github.com/microsoft/referencesource
.NET Core基类库：https://github.com/dotnet/corefx
.NET Core CLR：https://github.com/dotnet/coreclr
Roslyn编译器：https://github.com/dotnet/roslyn
MVC五、Web API二、Web Pages3框架源码：https://github.com/aspnet/AspNetWebStack
.NET Standard：https://github.com/dotnet/standard
KestrelHttpServer用于ASP.NET Core的跨平台Web服务器：https://github.com/aspnet/KestrelHttpServer
Visual Studio Code源码：https://github.com/Microsoft/vscode
一些优秀的.NET库、工具、框架、软件开源集合：https://github.com/quozd/awesome-dotnet
一些经常使用框架对ASP.NET Core和.NET Core的支持报告：https://github.com/jpsingleton/ANCLAFS
一些.NET下用于支持开发的开源项目集合：https://github.com/Microsoft/dotnet/blob/master/dotnet-developer-projects.md
微软出品的分布式框架orleans：https://github.com/dotnet/orleans
ML.NET 用于.NET的开源和跨平台机器学习框架：https://github.com/dotnet/machinelearning

Visual Studio

在文章最后，我还要简单的说下Visual Studio。

经过上文得知，只须要一个txt记事本+csc.exe咱们就能够开发出一个.NET程序，那么与之相比，.NET提供的开发工具VS有什么不一样呢？

咱们用记事本+csc.exe来编写一个.NET程序只适合小打小闹，对于真正要开发一个项目而言，咱们须要文件管理、版本管理、一个好的开发环境等。而vs ide则就是这样一个集成代码编辑、编译、调试、追踪、测试、部署、协做、插件扩展这样多个组件的集成开发环境，csc.exe的编译功能只是vs ide中的其中之一。使用vside开发能够节省大量的开发时间和成本。

sln解决方案

当你用VS来新建一个项目时，VS会先为你新建一个总体的解决方案。这个解决方案表现为.sln和.suo后缀格式的文件，它们均是文本文件，对解决方案右键属性能够进行相应的修改，也能够直接用记事本打开。

在sln中，定义了解决方案的版本及环境，如包含的项目，方案启动项，生成或部署的一些项目配置等，你能够经过修改或从新定义sln来更改你的整个解决方案。
而suo则包含于解决方案创建关联的选项，至关于快照，储存了用户界面的自定义配置、调试器断点、观察窗口设置等这样的东西，它是隐藏文件，可删除但建议不要删除。

咱们能够经过对比各版本之间的sln来修改sln,也能够使用网上的一些转换工具，也能够直接点击VS的文件-新建-从现有代码建立项目来让项目在不一样VS版本间切换。
Visual Studio 2010 - # Visual Studio 4.0
Visual Studio 2012 - # Visual Studio 4.0
Visual Studio 2013 - # Visual Studio 12.00
Visual Studio 2015 - # Visual Studio 14
Visual Studio 2017 - # Visual Studio 15

项目模板

VS使用项目模板来基于用户的选择而建立新的项目，也就是新建项目中的那些展现项(如mvc5项目/winform项目等等)，具体表现为包含.vstemplate及一些定义的关联文件这样的母版文件。将这些文件压缩为一个 .zip 文件并放在正确的文件夹中时，就会在展现项中予以显示。

用户能够建立或自定义项目模板，也能够选择现有的模板，好比我建立一个控制台项目就会生成一个在.vstemplate中定义好的Program.cs、AssemblyInfo.cs(程序集级别的特性)、App.config、ico、csproj文件

csproj工程文件

这里面，csproj是咱们最多见的核心文件，CSharp Project，它是用于构建这个项目的工程文件。

csproj是基于xml格式的MSBuild项目文件，其仍然是文本文件，能够打开并修改定义了的工程构造的属性，好比选择性的添加或删除或修改包含在项目中的文件或引用、修改项目版本、将其转换为其它类型项目等。

MSBuild是微软定义的一个用于生成应用程序的平台(Microsoft Build Engine)，在这里为VS提供了项目的构造系统，在微软官方文档上有着详细的说明：https://msdn.microsoft.com/zh-cn/library/dd393573.aspx、https://docs.microsoft.com/zh-cn/visualstudio/msbuild/msbuild

项目属性杂项

如今，简单说明一下csproj文件的一些核心元素。咱们用vs新建一个控制台项目，而后对项目右键属性打开项目属性，在应用程序页咱们能够定义：程序集名称(生成出来的程序集以程序集名称做为文件名，至关于csc中的/out)、默认命名空间(每次新建类里面显示的命名空间)、目标框架、应用程序类型、程序集信息(AssemblyInfo中的信息)、启动对象(可同时存在多个Main方法，需指定其中一个为入口对象)、程序集资源(一些可选的图标及文件)

1.在生成页有：

条件编译符号(全局的预编译#define指令，不用在每一个文件头部定义，至关于csc中的/define)
定义DEBUG/TRACE常量(用于调试输出的定义变量，如智能追踪的时候能够输出该变量)
目标平台(指定当前面向什么处理器生成的程序集，至关于csc中的/platform。选择x86则生成的程序集生成32位程序，能在32/64位Intel处理器中使用。选择x64则生成64位，只能在64位系统中运行。选择Any CPU则32位系统生成32位，64位系统则生成64位。注意：编译平台和目标调用平台必须保持一致，不然报错。生成的32位程序集不能调用64位程序集，64位也不能调用32位)、首选32位(若是目标平台是Any CPU而且项目是应用程序类型，则生成的是32位程序集)
容许不安全代码(unsafe开关，在c#中进行指针编程，如调换a方法和b方法的地址)
优化代码(至关于csc中的/optimize，优化IL代码让调试难以进行，优化JIT代码)
输出路径(程序集输出目录，可选择填写相对路径目录或绝对路径目录)
XML文档文件(至关于csc中的/doc，为程序集生成文档注释文件，浏览对方程序集对象就能够看到相关注释，VS的智能提示技术就运用于此)
为COM互操做注册(指示托管应用程序将公开一个 COM 对象,使COM对象能够与托管应用程序进行交互)

2.在高级生成设置中有:语言版本(能够选择C#版本)、调试信息(至关于csc中的/debug。选择none则不生成任何调试信息，没法调试。选择full则容许将调试器附加到运行程序，生成pdb调试文件。选择pdb-only，自.NET2.0开始与full选项彻底相同，生成相同的pdb调试文件。)、文件对齐(指定输出文件中节的大小)、DLL基址(起点地址)

3.在生成事件选项中能够设置生成前和生产后执行的命令行，咱们能够执行一些命令。

4.在调试选项中有一栏叫：启用Visual Studio承载进程，经过在vshost.exe中加载运行项目程序集，这个选项能够增长程序的调试性能，启用后会自动在输出目录生成{程序集名称}.vshost.exe这样一个文件，只有当当前项目不是启动项目的时候才能删除该文件。

IntelliTrace智能追溯

还要介绍一点VS的是，其IntelliTrace智能追溯功能，该功能最先存在于VS2010旗舰版，是我用的最舒服的一个功能。

简单介绍，该功能是用来辅助调试的，在调试时可让开发人员了解并追溯代码所产生的一些事件，而且可以进行回溯以查看应用程序中发生的情形，它是一个很是强大的调试追踪器，它能够捕捉由你代码产生的事件，如异常事件、函数调用(从入口)、ADO.NET的命令(Sql查询语句...)、ASP.NET相关事件、代码发送的HTTP请求、程序集加载卸载事件、文件访问打开关闭事件、Winform/Webform/WPF动做事件、线程事件、环境变量、Console/Trace等输出...

咱们能够经过在调试状态下点击调试菜单-窗口-显示诊断工具，或者直接按Ctrl+Alt+F2来唤起该功能窗口。

固然，VS还有其它强大的功能，我建议你们依次点完菜单项中的调试、体系结构、分析这三个大菜单里面的全部项，你会发现VS真是一个强大的IDE。比较实用且方便的功能举几个例子：

好比从代码生成的序列图，该功能在vs2015以前的版本能够找到(https://msdn.microsoft.com/en-us/library/dd409377.aspx 、https://www.zhihu.com/question/36413876)

好比模块关系的代码图，能够看到各模块间的关系

好比对解决方案的代码度量分析结果

好比调试状态下函数调用的代码图，咱们能够看到MVC框架的函数管道模型

以及并行堆栈状况、加载的模块、线程的实际状况

还有如进程、内存、反汇编、寄存器等的功能，这里再也不一一展现

连接

有关解决方案：https://msdn.microsoft.com/zh-cn/library/b142f8e7(v=vs.110).aspx
有关项目模板： https://msdn.microsoft.com/zh-cn/library/ms247121(v=vs.110).aspx
有关项目元素的说明介绍：https://docs.microsoft.com/zh-cn/previous-versions/visualstudio/visual-studio-2010/16satcwx(v%3dvs.100)
有关调试更多内容：https://docs.microsoft.com/zh-cn/visualstudio/debugger/
有关代码设计建议：https://docs.microsoft.com/zh-cn/visualstudio/code-quality/code-analysis-for-managed-code-warnings
有关IntelliTrace介绍：https://docs.microsoft.com/zh-cn/previous-versions/visualstudio/visual-studio-2010/dd264915(v%3dvs.100)

建议

我热爱编程。

我知道大多数人对技术的积累都是来自于日常工做中，工做中用到的就去学，用不到就不学，学一年的知识，而后用个五六年。
我也能理解人的理想和追求不一样，有的人可能就想平淡点生活。有的人多是过了拼劲，习惯了安逸。有的人已经认命了。
而我如今也天天饱满工做没多少时间，但在下班之余我仍然坚持天天都看一看书。
想学没时间学，想拼不知道往哪拼。有埋汰本身脑壳笨的，有说本身不感兴趣的。有明明踌躇满志，但总三天捕鱼两天晒网的。我身边的朋友大多都这样。

我想说，尽管咱们每一个人的境遇、思想、规划不一样，但我确定你们大部分是出于生计而工做。
而出于生计，那就是为了本身。而既然是为了本身，那就别天天浑浑噩噩过，即便你因各类缘由而没有斗志。

编程来不得虚的，若是你没走上管理，那么你的技术好就是好，很差就是很差，混不得，一分技术一分钱。本身不扎实，你运气就不可能太好。
技术是相通的，操做系统、通讯、数据结构、协议标准、技术规范、设计模式，语言只是门工具。要知其然也要知其因此然，只知道1个梨+1个梨=2个梨，不知道1个苹果+1个苹果等于啥就悲剧了。

那怎样提高本身？确定不能像以前那样被动的去学习了。
光靠工做中的积累带来的提高是没有多少。你不能靠1年的技术重复3年的劳动，本身不想提高就不能怨天尤人。
上班你们都同样，我认为成功与否取决于你的业余时间。你天天下班不管再苦都要花一个小时来学习，学什么都行，确定能改变你的人生轨迹。
好比你天天下班后都用一小时来学一个概念或技术点，那么300天就是300个概念或者技术点，这是何等的恐怖。

固然，这里的学要有点小方法小技巧的。不能太一条道摸到黑的那种，虽然这样最终也能成功，而且印象还深入，可是总归效率是有点低的。
好比你从网上下载个项目源码，你项目结构不知道，该项目运用技术栈也不太了解，就一点一点的开始解读。这是个提高的好方法，但这样很累，能够成功，可是很慢。见的多懂的少，每每会由于一个概念上的缺失而在一个细小的问题上浪费很长时间。或者说一直漫无目的的看博客来了解技术，那样获取的知识也不系统。

个人建议是读书，书分两类，一类是讲底层概念的一类是讲上层技术实现的。
能够先从上层技术实现的书读起(如何链接数据库、如何写网页、如何写窗体这些)。在有必定编程经验后就从底层概念的书开始读，操做系统的、通讯的、数据库的、.NET相关组成的这些...
读完以后再回过头读这些上层技术的书就会看的更明白更透彻，最后再琢磨git下来的项目就显得轻松了。

就.NET CLR组成这一块中文书籍比较少，由浅到深推荐的书有你必须知道的.NET(挺通俗)，CLR C#(挺通俗，进阶必看)，若是你想进一步了解CLR，能够看看园子里包建强http://www.cnblogs.com/Jax/archive/2009/05/25/1488835.html 和中道学友http://www.cnblogs.com/awpatp/archive/2009/11/11/1601397.html翻译的书籍及文章，固然若是你英语合格的话也能够直接阅读他们翻译的来源书籍，我这里有Expert .NET 2.0 IL Assembler的机器翻译版，同时我也建议从调试的方面入手，如 NET高级调试(好多.NET文件调试、反编译的文章都是参考这本书和Apress.Expert.dot.NET.2.0.IL.Assembler(这本书我有机器翻译版)的内容)或者看看Java的JVM的文章。
欢迎加群和我交流(书籍我都放在群文件里了)

如今技术发展很快，我建议你们有基础的能够直接看官方文档，(详细连接我已经在各小节给出)如下是部分经常使用总连接：

asp.net指南：https://docs.microsoft.com/zh-cn/aspnet/#pivot=core
Visual Studio IDE 指南：https://docs.microsoft.com/zh-cn/visualstudio/ide/
C# 指南： https://docs.microsoft.com/zh-cn/dotnet/csharp/
.NET指南：https://docs.microsoft.com/zh-cn/dotnet/standard/
微软开发文档：https://docs.microsoft.com/zh-cn/

最后送给你们我常常作的两句话：
1.先问是否是，再问怎样作，最后我必定会问为何
2.没人比谁差多少，相信本身，坚持不断努力，你也能成功

我喜欢和我同样的人交朋友，不被环境影响，本身是本身的老师，欢迎加群 .Net web交流群， QQ群：166843154 欲望与挣扎

做者：小曾
出处：https://www.cnblogs.com/1996V/p/9037603.html 欢迎转载，但请保留以上完整文章，在显要地方显示署名以及原文连接。
.Net交流群， QQ群：166843154 欲望与挣扎

个人博客即将同步至腾讯云+社区，邀请你们一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=367ug8kkmjk0s