.Net Core 前世今生（下）

        接上一篇《.net core 前世今生（上）》

        从本质上讲，按照CLI规范设计的.NET从其出生的那一刻就具有跨平台的基因。要实现开平台，主要需要解决两个问题，一是针对不同的平台设计相应的运行时为中间语言CIL提供一个一致性的执行环境，而是提供统一的BCL以彻底解决代码复用的难题。对于真正跨平台的.NET Core来说，微软不仅为它设计了针对不同平台被成为CoreCLR的运行时，同时还重新设计了一套被称为CoreFX的BCL。

        因此，.net core是新一代跨平台高性能开发框架，和.NET是完全不同的2个概念。

        如上图所示，NET Core目前支持的AppModel主要有两种，其中ASP.NET Core用于开发服务器Web应用和服务，而UWP（Universal Windows Platform）则用于开发能够在各种客户端设备（Mobile、PC、Xbox、Devices + IOT、HoloLens和Surface Hub等）上以自适应方式运行的Windows 10应用。

        CoreFX是经过完全重写的BCL，除了自身就具有跨平台执行的能力之外，其提供的API也不再是统一定义在少数几个单一的程序集中，而是经过有效分组之后被定义在各自独立的模块中。这些模块对应着一个单一的程序集，并最终由对应的NuGet包来分发。

        至于底层的虚拟机，微软则为主流的操作系统类型（Windows、Mac OS X和Linux）和处理器架构（x86、x64和ARM）设计了针对性的运行时，被称为CoreCLR。

        作为运行时的CoreCLR和提供BCL的CoreFX是.NET Core两根重要的基石，但是就开发成本来看，微软在后者投入的精力是前者无法比拟的。我们知道.NET Core自诞生到现在已经有好些年了，目前（2019.9）正式版还只是到了2.2（19年底发布3.0正式版），从发布进度上显得稍显缓慢，其中一个主要的原因是：重写CoreFX提供的基础API确实是一件繁琐耗时的工程，而且这项工程远未结束。为了对CoreFX提供的BCL有一个大致的了解，我们看看这些常用的基础API究竟定义在哪些命名空间下。

System.Collections：定义了我们常用的集合类型。

System.Console：提供API完成基本的控制台操作。

System.Data：提供用于访问数据库的API，相当于原来的ADO.NET。

System.Diagnostics：提供基本的诊断、调试和追踪的API。

System.DirectoryServices：提供基于AD（Active Directory）管理的API。

System.Drawing：提供GDI相关的API。

System.Globalization：提供API实现多语言以及全球化支持。

System.IO：提供针对文件输入输出相关的API。

System.Net：提供与网络通信相关的API。

System.Reflection：提供API以实现与反射相关的操作。

System.Runtime：提供与运行时相关的一些基础类型。

System.Security：提供与数据签名和加解密相关的API。

System.Text：提供针对字符串/文本编码与解码相关的API。

System.Threading：提供用于管理线程的API。

System.Xml：提供API用以操作XML结构的数据。

        对于传统的.NET Framework来说，承载BCL的API几乎都定义在mscorlib.dll这个程序集中，这些API并不是全部都转移到组成CoreFX的众多程序集中，那些与运行时（CoreCLR）具有紧密关系的底层API被定义到一个叫做System.Private.CoreLib.dll的程序集中，所以下图反映了真正的.NET Core层次结构。我们在编程过程中使用的基础数据类型基本上都定义在这个程序集中，所以目前这个程序集的尺寸已经超过了10M。由于该程序集提供的API与运行时关联较为紧密，较之CoreFX提供的API，这些基础API具有较高的稳定性，所以它是随着CoreCLR一起发布的。

        虽然我们编程过程中使用到的绝大部分基础类型都定义在System.Private.CoreLib.dll程序集中，但是这却是一个“私有”的程序集，我们可以从其命名看出这一点。我们将System.Private.CoreLib.dll称为一个私有程序集，并不是说定义其中的都是一些私有类型，而是因为我们在编程的过程不会真正引用这个程序集，这与.NET Framework下的mscorlib.dll是不一样的。不仅如此，当我们编写的.NET Core代码被编译的时候，编译器也不会链接到这个程序集上，也就是说编译后生成的程序集中同样也没有针对该程序集引用的元数据。但是当我们的应用被真正执行的时候，所有引用的基础类型全部会自动 “转移” 到这个程序集中。至于如何实现运行过程中的类型转移，请参考Type Forwarding技术。

        虽然.NET Core借助于CoreCLR和CoreFX实现了真正的跨平台，但是目前的.NET Core仅仅提供ASP.NET Core和UWP这两种编程模型，虽然后者旨在实现多种设备的统一编程，但依然还是关注于Windows平台。

        对于传统.NET Framework下面向桌面应用的WPF和Windows Forms，它们并没有跨平台的意义，所以依然是今后.NET的一大分支。除此之外，虽然我们有了跨平台的ASP.NET Core，传统的ASP.NET依然被保留了下来，并且在今后一段时间内还将继续升级。

        除了.NET Framework和.NET Core，.NET还具有另一个重要的分支，那就是Xamarin，它可以帮助我们为iOS、OS X和Android编写统一的应用。在.NET诞生十多年后，微软开始对.NET进行了全新的布局，建立了 “大一统” 的.NET平台。

        总的来说，这个所谓的大一统.NET平台由如下图所示的.NET Framework、.NET Core和Xamarin这三个分支组成。

        虽然被微软重新布局的.NET平台只包含了三个分支，但是之前遇到的一个重要的问题依然存在，那就是代码的复用，说的更加具体的是应该是程序集的复用而不是源代码的复用。对于全新的.NET平台来说，这个问题通过提供统一的BCL得到根本的解决，这个统一的BCL被称为.NET Standard。目前已经更新为2.0版本。如下图所示，.NET Standard为.NET Framework、.NET Core和Xamarin提供了统一的API，那么我们在这组标准API基础上编写的代码自然就能被所有类型的.NET应用复用。

        .NET平台的三大分支（.NET Framework、.NET Core和Xamarin）按照自己的方式各自实现了.NET Standard规定的这套标准的API。由于在运行时真正承载.NET Standard API的类型被分布到多个程序集中，所以. NET Standard程序集能够被复用的前提是运行时能够将这些基础类型链接到对应的程序集上。

        .net跨平台牵涉的知识点太多，以本人的能力水平暂时能够理解这些。有兴趣深入研究的可以访问 .net跨平台的奥秘