本篇文章给大家谈谈易于理解：什么是.NET？NET框架？NET 核心？ （更全面），以及对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
微软是全球最大的计算机软件提供商。为了占领开发者市场，它于2002年推出了Visual Studio（简称VS，微软向开发者提供的工具集）.NET 1.0版本的开发者平台。为了吸引更多的开发者加入该平台，微软还推出了.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平台支持的任何语言通用。
与其说它是一条规则，不如说它是一套语言互操作性的标准规范。它就是公共语言规范，简称CLS。
CLS在类型、命名、事件、属性、数组等方面提供了语言的通用定义和规范，这些东西提交给欧洲计算机制造协会ECMA，称为：公共语言基础设施。
在类型方面，CLS定义了符合C#语言规范的类型和不符合C#语言规范的类型：
当然，从编码的角度来看，我们不必阅读那些详细的文档。为了方便开发者开发，NET提供了一个功能叫做：CLSCompliantAttribute。代码被标记了CLSCompliantAttribute后，如果你写的代码不符合CLS规范，编译器会给你一个警告。
值得一提的是，CLS规则仅适用于那些可以被其他程序集公开访问的成员，例如public和inherited protected。对于程序集的内部成员（例如Private和internal），不会执行此检测规则。换句话说，适配的CLS合规规则只是那些公共成员，而不是私有实现。
那么是否有特殊情况，比如当我使用反射技术访问程序集中不属于当前语言的类型时会发生什么情况？
答案是，你可以尝试，例如使用VB反射来访问C#中的char*指针类型。即使VB中没有char*等等价的指针类型，mscorlib还是为指针类型提供了一个Pointer包装类来进行访问，可以从运行时类携带的类型名看到其原始类型名。
正如您所看到的，此类中的元素不符合CLS 规范。
CLS 例外
说到特殊情况，还需要提一下异常处理。异常类型系统是在.NET框架中定义的。从编译器的角度来看，catch捕获的所有异常都必须继承自System.Exception。如果要调用不遵循此规范的语言抛出的其他类型的异常对象（C++ 允许抛出任何类型的异常，例如C# 调用C++ 代码和C++ 抛出字符串类型异常）。 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 开发中，编写跨语言组件时遵循的共性称为通用语言规范(CLS)。
什么是CTS？
如果你明白了什么是CLS，那么你就会很容易明白什么是CTS。
假设你围绕封装、继承、多态这三个特性设计了多种面向对象语言。你发现大家都是面向对象的，能够很好的表达现实生活中的对象模型。除了语法和功能上的差异外，语言的定义和设计结构实际上是相同的。
例如，在现实中，你看到一辆汽车，里面坐着两个人。你如何用这种语言来表达这样一个概念和场景？
首先，我们需要为这种语言横向定义一个“类型”的概念。接下来，在程序中可以这样表达：有一个汽车类型，有一个人物类型，一个汽车类型对象包含两个人物类型对象。因为为了表达这个模型，你引入了“对象”的概念。而现在，你看到车里的人做出类似驾驶的动作，你就引入了“动作命令”的概念。
然后，你突然意识到并得出一个定理。无论是哪一种“类型”，都只会有一种特征，即具有生命特征的活者（如人）和无生命特征的死者（如汽车）。两者之一。最后，随着心智模型的成熟，你发现这个“类型”相当于一套富含学科特征的指令。
好，那你就开始抄葫芦吧。如果参考其他编程语言，你会发现大家都用class来表示类的含义，用struct来表示结构体的含义，用new来表示创建新对象的含义。因此，您还使用class 和new 作为这部分函数的语法。用关键词来表示。然后你发现他们也用了很多关键词来更丰富的表达这些现实生活中的模型，比如override、virtual等等。因此，经过不断的思想升级和借鉴，你仔细分析了设计语言过程中思想的变化，抽象总结这个语言体系，最后总结出一个体系。
所以你给别人这么说，我总结了很多语言中必须的东西，比如两个主要类别：值类别和引用类别，五个主要类型：类、接口、委托、结构体和枚举。我还规定现在，类型可以包含字段、属性、方法、事件和其他成员。我还规定了每个类型的可见性规则和类型成员的访问规则等等等等，只要语言是按照我的系统来设计的，设计的语言可以有很多好的特性，比如跨语言C#和VB.net之所以能这样，是因为这两种语言的设计很适合我的系统。
那么，什么是CTS？
当你需要为.Net设计一种语言时，你需要遵循一个系统（.Net平台下的语言支持的系统）。本系统为CTS（Common Type System），包括但不限于：
构建跨语言执行框架。提供面向对象的模型，支持在.NET实现之上实现的各种语言。所有语言在定义处理类型时都必须遵循的一组规则（CLS）。提供包含应用程序开发中使用的基本原始数据类型（例如Boolean、Byte、Char等）的库。上面的CLS 是CTS（通用类型系统）系统的子集。
如果一种编程语言可以支持CTS，那么我们称其为.NET 平台的语言。
官方CTS介绍：https://docs.microsoft.com/zh-cn/dotnet/standard/common-type-system
Microsoft 已将CTS 和.NET 的其他一些组件提交给ECMA，使其成为公共标准。最终标准称为CLI（公共语言基础设施）。
所以有时你看到的一些书籍或文章只提到CTS，有些只提到CLI。请不要感到惊讶。您可以广泛地将它们理解为同一事物。 CLI 是Microsoft 向国际组织提交CTS 和其他内容的时间。制造协会ECMA 的行业标准。
什么是类库？
CTS中有一项需要原始数据类型的类库。我们先来了解一下什么是类库？类库是类的逻辑集合。在你的开发工作中，你自己使用过或者编写过很多工具类，比如JsonHelper，等等这样的项目。我们可以从逻辑上将这些类的集合称为“类库”。例如，这些Helper统称为工具类库。
什么是基本类库BCL？
当你通过VS创建项目时，你的项目已经引用了一些.NET语言编写的类库。例如，在控制台中，可以直接使用Console类来输出信息，也可以通过File类使用System.IO来读写文件。这些类是微软为你编写的，你不需要自己编写。它可以帮助您编写面向.NET 的开发语言中使用的基本功能。这个类被称为BCL（Base Class Library），大部分都包含在System命名空间中。
基础类库BCL包括：基本数据类型、文件操作、集合、自定义属性、格式设置、安全属性、I/O流、字符串操作、事件日志等。
什么是框架类库FCL？
关于BCL这里我就不详细说了。NET这么大，发展至今，微软也写了越来越多的类库来帮助开发者，这让我们开发者开发起来更加容易。微软开发的类库统称为：FCL、Framework Class Library、NET Framework Class Library。我上面表达的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 定义根类。当我们描述这样一类对象时，有两种写法，如图：
我们可以看到上面可以描述首字母小写的蓝色字符串和对象，也可以描述首字母大写的浅蓝色字符串和对象。这两种表达有什么区别？
要知道，在vs的默认配色方案中，蓝色主体代表关键字，浅蓝色主体代表类型。
所以这意味着微软提供的FCL类库包含了一些用来描述数据类型的基本类型。无论我们使用什么语言，只要引用了FCL，我们就可以使用一个新的类来表示Expression数据类型。
如图所示：
使用new来创建这些类型的对象，但是这样太麻烦了，所以C#用int关键字来表示System.Int32，用string关键字来表示System.String等，所以我们可以这样写。
直接在编译器中表达的类型称为原始类型，它们直接映射到BCL 中的具体类。
下面是面向.NET的语言的一些原始类型和对应的BCL的类图：
System.Object的含义
说到类型，这里有一个CTS定义的非常重要的规则，就是类之间只能有单一继承。 System.Object 类是所有类型的根。任何类都显式或隐式地从System 继承。目的。
因此，Object不仅是C#语言的类型根，也是VB等所有面向.NET的语言的类型根。它是整个FCL的类型根。
当然，CTS定义了单继承。许多编程语言都满足这个规则，但也有例外。例如，C++没有继承限制，可以继承多个。 C++/CLI 是.NET 的CLI 实现。如果在非托管代码中可以实现多重继承。如果尝试在托管代码中继承多重继承，将会报告错误。我已经举过此类特殊情况的例子。这也反映出CTS对各种语言的支持并不像C#那么全面。我们只需要清楚地记住一件事：符合CTS的部分自然会遵循CTS定义的规则。任何可以遵循CTS 类型规范并具有.NET 运行时实现的编程语言都可以成为.NET 的成员。
计算机如何运行程序？
接下来我想谈谈什么是.NET跨平台，解释为什么它可以跨语言。但如果你想知道什么是跨平台，你首先要知道一个程序是如何在本机上运行的。
什么是CPU
CPU，全称是CentralProcessingUnit，称为中央处理单元。它是一种超大规模集成电路，是构成计算机中不可缺少的组成硬件。没有它，计算机就只是一个外壳。
无论你的编程水平如何，首先你应该知道CPU是计算机的计算核心和控制核心。 CPU从内存或高速缓冲存储器中取出指令，放入指令寄存器，对指令进行译码并执行。
当我们运行一个程序时，CPU会不断读取程序中的指令并执行它们，直到程序关闭。事实上，从计算机开机开始，CPU就一直在不断地执行指令，直到计算机关闭为止。
什么是高级编程语言
从计算机的角度来看，每种CPU 类型都有自己可以识别的指令集。无论你的程序是用什么语言编写的，计算机最终都只能识别其CPU可以识别的二进制指令集。
在计算机发展的早期，人们直接输入01010101这样没有语义的二进制指令来让计算机工作。可读性几乎不存在。没有人愿意直接编写那些不可读、繁琐、耗时且容易出错的指令。错误的二进制01代码，所以编程语言是后来出现的。
编程语言的诞生，使得人们写的代码更具可读性和语义性，比直接使用01更有利于记忆。
前面提到，计算机最终只能识别二进制指令，所以我们用编程语言编写的代码必须转换成机器可以识别的指令。
像这样：
code: 1+2函数翻译方式（参数：code）
{
.
'1'='001'；
'2'='002'； '+'='000';
返回机器可以识别的二进制代码；
}
调用翻译方法('1+2')='001 000 002'
因此，需要一个翻译过程，将用编程语言编写的代码文件转换为本地机器可以识别的指令。
我们的计算机现在带有操作系统。仅仅将它们翻译成机器指令是不够的。代码文件必须转换成操作系统可以执行的程序。
那么这几个步骤就是对应编程语言的编译过程的工程化。这个翻译过程需要一个工具来完成，我们称之为编译器。
不同厂家的CPU有不同的指令集。为了克服面向CPU的指令集难以阅读、编程、记忆、容易出错的缺点，后来出现了针对特定CPU的专用汇编语言。例如，我输入x86这样的汇编指令mov ax,bx，然后使用机器代码制成的汇编器，它将被翻译成二进制01格式的机器指令，例如1000100111011000。
不同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版本之后出现了变化。这些标记的异常默认情况下不会在托管环境中抛出（即无法捕获），而是由操作系统的SEH机制处理。
不过，如果你仍然想在代码中捕获并处理此类异常，可以在需要捕获的方法上标记[System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute]属性，就可以在方法中捕获此类异常。异常。您还可以通过在配置文件中添加运行时节点来执行此类全局配置：
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
什么是CLR、NET虚拟机？
事实上，NET不仅提供了自动内存管理支持，还提供了类型安全、应用程序域、异常机制等一系列支持，统称为CLR公共语言运行时。
CLR 是.NET 类型系统的基础。所有.NET 技术都建立在它之上。熟悉它可以帮助我们更好地理解框架组件的核心和原理。
在执行托管代码之前，我们总是先运行运行时代码。通过运行时代码的调用，形成一个运行环境来支持托管程序，从而完成诸如无需开发人员手动管理内存和一组代码等任务。这种操作可以在各大平台上运行。
这个环境和系统非常完整，就像一个小系统，所以CLR通常被称为“.NET虚拟机”。所以，如果我们把进程作为最底层的话，进程的顶层就是.NET虚拟机（CLR），而虚拟机的顶层就是我们的托管代码。换句话说，托管程序实际上托管在.NET 虚拟机中。
什么是CLR宿主进程、运行时宿主？
相应的，容纳.NET虚拟机的进程就是CLR宿主进程，这个程序称为运行时宿主。
这些运行库的代码都是用C/C++编写的，具体由mscoree.dll代表的核心dll文件来表示。该dll提供了很多构建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.即用于记录在源代码中所定义的类型的定义表：ModuleDef、TypeDef、MethodDef、ParamDef、FieldDef、PropertyDef、EventDef，2.引用了其它程序集中的类型成员的引用表：MemberRef、AssemblyRef、ModuleRef、TypeRef3. 用于描述一些杂项(如版本、发布者、语言文化、多文件程序集中的一些资源文件等)的清单表：AssemblyDef、FileDef、ManifestResourceDef、ExportedTypeDef1)程序入口方法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编译成一个可执行的控制台程序的。 后关闭记事本，将之.txt的后缀改为.cs的后缀(后缀是用来标示这个文件是什么类型的文件，并不影响文件的内容)。 我已经在前面讲过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属性来添加搜索目录，不过只能填写相对路径： //程序集当前目录下的相对路径目录，用;号分割 2.如果程序集是强签名后的，那么可以通过codeBase来指定网络路径或本地绝对路径。 publicKeyToken="32ab4ba45e0a69a1" culture="neutral" /> href="http://www.litwareinc.com/myAssembly.dll" /> 当然，我们还可以在代码中通过AppDomain类中的几个成员来改变搜索规则，如AssemblyResolve事件、AppDomainSetup类等。 有关运行时节点的描述:https://docs.microsoft.com/zh-cn/dotnet/framework/configure-apps/file-schema/runtime/runtime-element 项目的依赖顺序 如果没有通过config或者在代码中来设定CLR搜索程序集的规则，那么CLR就按照默认的也就是我上述所说的模式来寻找。 值得一提的是，项目间的生成是有序生成的，它取决于项目间的依赖顺序。 比如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.Convert(); } 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的错误。 这是为什么？ 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。 那么，如果我执意如此，有什么好的解决方法能让程序顺利执行呢？有，有2个方法。 第一种：通过bindingRedirect节点重定向，即当找到10.0的版本时，给定向到6.0版本 如何在编译时加载两个相同的程序集？ 注意：我看过有的文章里写的一个AppDomain只能加载一个相同的程序集，很多人都以为不能同时加载2个不同版本的程序集，实际上CLR是可以同时加载Newtonsoft.Json 6.0和Newtonsoft.Json 10.0的。 第二种：对每个版本指定codeBase路径，然后分别放上不同版本的程序集，这样就可以加载两个相同的程序集。 如何同时调用两个两个相同命名空间和类型的程序集？ 除了程序集版本不同外，还有一种情况就是，我一个项目同时引用了程序集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 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域就会各存在内存地址不同但数据相同的程序集数据。
用户评论
终于明白了!之前一直搞不懂.NET Framework 和 .NET Core的区别，这篇文章解释得非常清楚，把复杂的技术概念用语言理解的来表达，简直太棒了！受益匪浅!
有6位网友表示赞同！
我也是从事软件开发的，这篇博客对于快速了解.NET Ecosystem很有帮助。虽然文章详细介绍了不少历史细节，但还是希望能更直观的展示不同版本在实际应用中的区别，比如哪个版本适合小型项目，哪个适合企业级应用程序等。
有17位网友表示赞同！
作为一名刚入门编程的学生来说，这篇文章让我对.NET有了一定的了解，感觉.NET Framework和 .NET Core 确实有很多差别，尤其是在互操作性方面。我会仔细阅读文章中的例子，并尝试学习相关的开发经验。
有12位网友表示赞同！
讲的还挺通俗易懂的！不过我个人觉得 .NET Framework 有点臃肿了，而且现在市场上.NET Core 应用越来越常见，是不是应该更倾向于学习 .NET Core 呢?
有15位网友表示赞同！
.NET Framework 我以前了解过一些，但是.NET Core 比较陌生。这篇博客帮助我理解了它们之间的关系以及各自的特点，我觉得学习这两套技术都很有价值。
有10位网友表示赞同！
这个标题说的挺吸引人的，一看就是对新手友好的文章！确实很多开发者在入门阶段很容易被这些框架的名称搞混淆呢！希望以后能写更多这样简单易懂的博文!
有19位网友表示赞同！
文章内容比较翔实，但部分文字堆砌一些技术术语可能不利于初学者理解。建议可以加入更多图表或案例来辅助说明，增强可读性。
有10位网友表示赞同！
学习.NET Framework 之前我还以为是单一的版本，没想到还有.NET Core 这个分支。这篇文章给我明确了解了它们各自的定位和优势，很好的帮助我梳理了 .NET 技术生态链！
有19位网友表示赞同！
感觉文章重点偏向于历史演变和技术细节，如果能进一步解释在实际项目中如何选择合适的.NET 版本，更有实用价值。
有20位网友表示赞同！
.NET Framework已经是很老的技术了，现在更应该关注.NET Core。希望以后的文章可以多讨论 .NET 6、.NET 7的发展方向和未来趋势
有15位网友表示赞同！
作为一名资深的开发工程师，我觉得这篇文章对 .NET 的历史概况分析比较全面，但缺少一些深度探讨。例如，对于最新版本的性能优化和跨平台能力增强等方面的细节可以再详细描述一下。
有9位网友表示赞同！
总的来说不错，文章逻辑清晰，用通俗易懂的语言介绍了.NET Framework 和 .NET Core 的主要特点。尤其对不同版本之间的差异分析很到位，对于想要深入学习.NET 技术的开发者很有帮助！
有17位网友表示赞同！
这篇文章对我现在想学习编程有很大帮助，但是有些技术细节还是比较复杂，希望文章可以添加更多图片或者视频来辅助理解。
有7位网友表示赞同！
对入门者来说，这篇博客确实很容易理解. 但是对于更深入的技术架构和性能优化方面，可能需要阅读更专业的文档或书籍才能更好地掌握。建议结合其他学习资源进行补充学习！
有6位网友表示赞同！
这篇文章帮助我初步了解了 .NET Framework 和 .NET Core 的区别，也让我意识到 .NET 技术的发展方向是朝着轻量级、跨平台的方向发展。作为一名开发者，需要不断学习和跟进最新的技术趋势!
有11位网友表示赞同！
作者的讲解风格比较幽默风趣，读起来比较容易理解. 建议可以加入更多实例代码来演示具体的使用场景，这样可以帮助读者更快地掌握 .NET 的相关知识点。
有13位网友表示赞同！