.Net Core 前世今生（上）

        .net framework（以下简称.net）是微软在2000年发布的主要用于开发桌面程序和web程序的集成平台。

        .net core（以下简称core）是微软在2016年发布，目前已经迭代到3.0版本。

        那么core是不是针对原来.net简单的版本提升呢？显然不是！

        首先来说.net，从框架（平台）结构层次来讲，由下图两个层次构成，分别是.net程序运行环境CLR（Common Language Runtime 通用语言运行环境），以及给开发人员提供的api库FCL（Framework Class Library 框架类库）

        CLR的意义对于.net来说，就像JVM对于java，它其实也算一个虚拟机。CLR为程序的运行提供了执行环境，包括提供内存分配、垃圾回收、安全控制、异常处理和多线程管理等方面的服务。到目前（2019年）为止，微软仅仅发布了4个版本的CLR，分别是1.0，1.1，2.0，4.0。

.net framework 1.0 和 1.1 分别采用 CLR 1.0 和 1.1

.net framework 2.0 和 3.x 统一使用 CLR 2.0

.net framework 4.x 则使用 CLR 4.0

        FCL是为开发人员提供的api类库。由它提供的api又可以划分成上图所示的两个层次。

        处于最底层的部分被称为BCL（Basic Class Library 基础类库），它提供了一系列基础类型，它们用于描述一些基本的数据类型和数据结构（比如字符串、数字、日期/时间和集合等）和提供一些基础性的操作（比如IO、诊断、反射、文本编码、安全控制、多线程管理等）。

（using System, System.DateTime, System.String, System.IO... 这些字母熟悉么，他们都存在于mscorlib.dll这个程序集中，也就是BCL，当然只是其中之一）

        在BCL之上的则是面向具体应用提供的API类库（Application Model），我们大体上可以将它们划分为入下三种类型：

面向应用（比如ASP.NET、WPF和Windows Forms等）

面向服务（比如WCF、WF和Data Services等）

面向数据（比如ADO.NET、Entity Framework和LinQ to SQL等）

        .NET在不断升级过程中使自己变得更加强大和完备，但另一方面也使自己变得越来越臃肿。随着版本的不断升级，构成.NET的应用模型（AppModel）、基础类库（BCL）和运行时（CLR）都在不断地膨胀，下图很直观地说明了这个问题。(横坐标是.net版本，最新版已经是4.8)

        我们知道程序集（dll）是.NET最基本的部署单元，不论定义其中的多少类型被使用，运行时（CLR）总是将整个程序集加载到内存中。对于上面介绍的构成.NET Framework的三个层次来说，应用模型是针对具体应用/服务类型的，相应的API通过独立的程序集来承载（比如ASP.NET的核心框架定义在程序集System.Web.dll中，承载整个Windows Forms框架的程序集则是System.Windows.Forms.dll），所以其实.NET的各个应用模型是相互独立的。在开发某种类型的应用时，我们只需要引用应用模型对应的程序集就可以了，如开发Windows Forms应用，是无需引用System.Web.dll程序集的。

        但是.NET为了对运行在本机（服务器）各种类型的托管程序提供支持，将所有应用类型的基础类型均定义在了BCL基础类库（绝大部分核心代码都定义在mscorlib.dll这个核心程序集中），所以基础类库（BCL）基本上来说是作为一个不可分割的整体存在于.NET之中。

        然而，在很多情况下，我们的应用可能仅仅需要使用到BCL一个很小的子集，但是我们不得不将定义整个程序集都加载到内存之中（虽然现在内存条很便宜，但是耗内存就代表了会影响性能）。对于移动和服务端应用（包括部署于云端应用）来说，由此带来的对性能和吞吐量的响应就成了一个不得不考虑的问题。

        理想的BCL消费方式是“按需消费”，我们需要那个部分就加载那个部分。由于作为独立部署单元的程序集总是作为一个整体被CLR加载到内存中，要完全实现这种理想的BCL消费方式，唯一的办法就是将其划分为若干小的单元，并分别定义到独立的程序集中。除此之外，按照模块化的原则对整个BCL进行拆分也是版本升级变得更加容易，如果现有版本具有需要修复的Bug，或者性能需要改进，那么只需要改动并升级相应的模块就可以了。下图展示了理想的具有模块化BCL的.NET层级结构。

        经过多年的经营，微软已经为我们构建了一个完整的支持多种设备的.NET生态系统，从最初单纯的桌面平台，逐渐扩展到移动、平板和嵌入式等平台。设备运行环境的差异性导致了针对它们的应用不能构建在一个统一的.NET Framework平台上，所以微软采用独立的.NET Framework平台来对它们提供针对性的支持。就目前来说，除了支持Windows 桌面和服务器设备的“完整版 .NET Framework”之外，微软还先后推出了一系列“压缩版.NET Framework”，这其中就包括Windows Phone、Windows Store、Silverlight和.NET Micro Framework等，它们分别对移动、平板和嵌入式设备提供支持。

        这些.NET Framework并不是仅仅在AppModel层次提供针对相应设备平台的开发框架，它们提供的BCL和Runtime也是不同。换句话说，这些.NET Framework平台是完全独立的，不同.NET Framework平台之间的独立性很直观地体现在下图之中。目标平台的独立性导致我们很难编写能够在各个平台复用的代码。更不用谈及跨平台。

        但是.net真的不能跨平台么？

        其实微软早就制定了一个标准规范用于跨平台，称为CLI（Common Language Infrastructure），然后提交给欧洲计算机制造商协会（ECMA：European Computer Manufacturers Association）并被后者接受，成为了一个编号为335的规范，所以CLI又被称为ECMA-335。只是由于商业运作，公司利益等原因，微软一直在windows上进行耕耘。

        CLI的制定旨在解决这样一个问题：由不同（高级）编程语言开发的.NET应用能够在无需任何更改的情况下运行于不同的系统环境下。要实现这个目标，必需有效地解决这里涉及到两种类型的差异，即编程语言的差异和运行时环境的差异。编程语言之间能够实现相互兼容、运行时环境能够得到统一，跨平台的伟业方能实现。

        编程语言有编译型和解释型之别，前者需要通过编译器进行编译以生成可执行代码，CLI涉及的Common Language指的是编译型语言。要实现真正的跨平台，最终需要解决的是可执行代码在不同平台之间的兼容和可移植的问题，而编程语言的选择仅仅决定了应用源文件的原始状态，应用的兼容性和可移植性由编译后的结果来决定。如果通过不同编程语言开发的应用通过相应的编译器编译后能够生成标准的目标代码，那么编程语言之间的差异就不再是一个问题了。

        按照CLI的规定，用来描述可执行代码的是一种叫做CIL（Common Intermediate Language）的语言，这是一种介于高级语言和机器语言之间的中间语言。如下图所示，虽然程序源文件由不同的编程语言编写，但是我们可以借助相应的编译器将其编译成CIL代码。原则上讲，我们可以设计出新的编程语言并将其加入到.NET大家庭中，只需配以相应的编译器生成统一的CIL代码即可。我们也可以为现有的某个编程语言设计一种以CIL为目标语言的编译器使之成为.NET语言。CIL是一门中间语言，同时也是一门面向对象的语言，所以对于一个CIL程序来说，类型是基本的组成单元和核心要素。微软制定了一个名为CTS（Common Type System）的规范为CLI确立了一个统一的类型系统。

        编程语言的差异通过编译器这个适配器得以“同一化”，运行环境的差异则可以通过虚拟机（VM：Virtual Machine）技术来解决。虚拟机是CIL的执行容器，它能够在执行CIL代码的过程中采用及时编译的方式将它动态地翻译成与当前执行环境完全匹配的机器指令。虚拟机屏蔽了不同操作系统之间的差异，让目标程序可以不做任何修改的情况下就能运行于不同的底层执行环境中，而CIL实际上是一种虚拟机语言。

        从实现原理来看，让.NET能够跨平台其实不难，但是让各种相关的人员参与进行以构建一个健康而完善的跨平台.NET生态圈则注定不是一件一蹴而就的事情，这里涉及的利益相关方包括编程语言的设计者，以及设计和开发编译器、虚拟机、IDE以及其他相关工具的人，当然还包括广大的应用开发者。

        综上所述，由于.NET是建立在CLI这一标准的规范之上，所以它天生就具有了“跨平台”的基因。在微软发布了第一个针对桌面和服务器平台的.NET Framework之后，它开始 “乐此不疲” 地对这个完整版的.NET Framework进行不同范围和层次的 “阉割” ，进而造就了像Windows Phone、Windows Store、Silverlight和.NET Micro Framework的压缩版的.NET Framework（看似一片繁荣，其实你懂的）。虽然这些都是.NET的子集，但是由于它们采用完全独立的运行时和基础类库，这使我们很难开发一个支持多种设备的“可移植（Portable）”应用，这些分支反而成为制约.NET发展的一道道枷锁。

文章节选自 https://www.cnblogs.com/artech/p/how-to-cross-platform-01.html