.NET Core 全新认识

来源：yubinfeng

cnblogs.com/yubinfeng/p/6626694.html

一、概述

.NET 经历14年，在Windows平台上的表现已经相当优秀，但是“跨平台、开源”却是其痛点，从16年开始.NET Core的出现将迎来.NET的真正意义上的跨平台和开源序幕。

.NET Core是一个开源通用的开发框架，支持跨平台，即支持在Window，macOS，Linux等系统上的开发和部署，并且可以在硬件设备，云服务，和嵌入式/物联网方案中进行使用。

.NET Core的源码放在GitHub上，由微软官方和社区共同支持。

下面了解一下.NET Framework和.NET Core这两个分支的异同。

.NET 开源项目：https://github.com/dotnet （包括standard、corefx（.NET 库）、coreclr（NET Core 运行时）、roslyn（Roslyn 编译器（C# 和 Visual Basic）和适用于 Visual Studio 的语言工具）、cli（命令行界面和工具）、orleans，此外还有一些文档包括：docs、docfx等）

二、.NET Framework和.NET Core的结构体系

.NET Framework 包含,Windows Form,WPF,ASP.NET
.NET Core 包含，UWP,ASP.NET Core
.Xamarin，新的.NET还包括第三个部分，即XAMARIN用于构建移动APP，包含iOS、 OS X 、Android等。

即所谓的.NET三架马车，下面是最新的.NET生态体系图：

从上图可以看出，.NET Framework和.NET Core及XAMARIN将是现在及未来.NET的三大部分，而它们三个都是独立于各自的，但都基于.NET标准库。

三、.NET Framework和.NET Core特点

.NET Core较之前的.NET Framework 从性能和开发效率上都有很大的提升。关键是首次实现了.NET的完全跨平台能力的基础技术栈。

.NET Core 基于跨平台能力，并没有将与 GUI 高度相关的 API 移植到 .NET Core 内，因此像是 Windows Forms 或是 Windows Presentation Foundation (WPF) 并未移植到 .NET Core。

.NET Core 支持控制台应用程序 (Console Application) 以及类库 (Class Library) 类型的项目。

不过微软在其 Universal Windows Platform (UWP) 开发平台使用了 .NET Core，并且利用 .NET Native 技术将其性能提升至十分接近原生码的速度。

ASP.NET Core 则以控制台应用程序驱动其托管环境 Kestrel Server 以支持 ASP.NET Core 程序的运行。

.NET Framework

（1）Windows应用程序的王者框架:.NET Framework用于创建基于Windows系统的应用程序，包括Windows From、WPF、ASP.NET MVC等。在Windows框架下的开发。.NET Framework仍是强项，今后一段时间将继续更新升级。

（2）开发语言选择：可选用C#,VB.NET,F#等众多语言开发。

.NET Core

（1）跨平台 .NET Core 是微软推出的最新的跨平台的框架，用它可以创建的应用可以运行在MAC，Linux上。 .NET Core 支持UWP 和 ASP.NET Core，UWP即Windows 10 中的Universal Windows Platform简称。即Windows通用应用平台，在Win 10 Mobile/Surface(Windows平板电脑）/PC/Xbox/HoloLens等平台上运行，uwp不同于传统pc上的exe应用也跟只适用于手机端的app有本质区别。它并不是为某一个终端而设计，而是可以在所有windows10设备上运行。

（2）开源 .NET Core从属于.NET基金会，由微软进行官方支持。使用MIT和Apache 2开源协议，文档协议遵循CC-BY

（3）兼容性：从前面的图上看出.NET Core和.NET Framework基于.NET Standard Library。因此与.NET Framework，Xamarin，Mono等兼容。

（4）灵活部署机制：第一种.Portable applications(便携式应用)这种部署机制和传统的.NET Framework相似，只要目标平台上存在.NET Core Runtime即可。

第二种.Self-contained application（自宿主应用）顾名思义，这种部署机制将应用和运行时共同打包，即便目标平台上没有安装.NET Core Runtime也能正常使用第二种方式和.NET Native也是不一样的，仍然使用 CoreCLR，而.NET Native使用CoreRT作为运行时，详细信息请见dotnet/corert

（5）命令行工具:.NET程序所有的运行脚本都可以用命令行工具执行(cmd，bash)。

（6）语言选择：.NET Core 1.0版本中支持的编程语言仅有C#（F#和VB暂未实现）

四、.NET Core构成体系

上面说到.NET的三驾马车，.NET Framework、.NET Core、XAMARIN,下面主要看一下.NET Core的组成

如上图，NET Core 构成体系：

（1） Runtime 在.NET Core 中有实现两种RunTime，NativeRuntime 和 CoreCLR。NativeRuntime 将C# 或 VB.net 代码直接转换为原生机器码。而CoreCLR是一个开源的JIT运行时，会将代码编译成中间语言（IL）在最终运行时再转换机器码。

（2） Unified BCL Base Classlibrary即基础类，例如 FileSystem、Console、XML操作等。

（3） Windows Store AppModel & ASP.NET Core 1.0 提供开发Windows系统的各种触屏设备和ASP.NET程序的一组基础库。

五、.NET Core各个功能模块

如上图：

应用层： .NET Core的系统构成，最上层是应用层，是开发基于UI应用的框架集，包括了ASP.NET Core(用于创建web app)，和 UWP(用于创建Windows10 app)。

中间层：中间层是公共库(CoreFX)：实现了.NET Standard Library ,囊括了常用系统级操作例如（文件、网络等）。在CoreFx下是运行时环境，.NET Core 包含了两种运行时(CoreCLR、CoreRT),CoreCLR是一种基于即时编译程序(Just in time compiler,JIT)的运行时,它使用了跨平台开源的编译器RyuJIT,而CoreRT是使用提前编译器(Ahead of time compiler,AOT)的运行时,它既可以使用RyuJIT来实现AOT编译也可以使用其他的AOT编译器。由于AOT提前编译IL成了机器码，在移动设备上也具有更好的启动速度和节能性。

编译器：最后还要提到一个开源的跨平台源代码编译器Roslyn，它有别于刚才两个编译器，JIT和AOT编译器主要用于将IL编译成本机机器码，而Roslyn是将C# 或 VB.NET 代码编译成程序中间语言(intermediate language,IL)。

下面介绍这个编译器。

（1）、.NET Core的Roslyn 编译器

Roslyn编译器用于将C#或VB.NET代码编译为程序集(assembly)，它的编译过程是一个管道式的处理过程一共包含4个步骤，具体过程见下图。

A. Parser(解析)

根据语法对源代码进行解析。

B. Declaration (声明)

为代码生成元数据(metadata),元数据是一个数据表的集合，描述了在当前代码中定义的数据类型和成员，同时也描述了引用的类型及成员。

C. Bind(绑定)

将生成的IL代码与描述它的元数据绑定在一起，生成托管模块(managed module)。

D. Emit(生成)

将一个或多个托管模块合并生成程序集(assembly)。

（2）RyuJIT 编译器

在程序运行中需要执行某一个方法，首先需要将已经编译好的IL转换本机的机器码，而这个任务就交给了RyuJIT。它是新一代JIT编译器，第一次实现了AMD64的架构，RyuJIT能够比JIT64(上一代编译器)更快地生成代码，以提高程序运行效率(测试详情链接)。

（3) CoreCLR & CoreRT

CoreCLR 和 CoreRT 都是.NET Core的运行时(Runtime),它们提供了与.NET Framework CLR 类似的核心功能(内存管理、程序集加载、安全性、异常、线程管理等)，可由面向于运行时的所有语言使用。

CoreRT 和 CoreCLR 不同的是，CoreRT 提供了一套AOT 的机制,可以将.NET Core程序编译成原生代码，不依赖 .NET 运行时而运行在宿主机器上。

除此之外两个运行时大部分功能代码是共享的，比如GC。AOT的优化带来不少好处：

编译后生成一个单文件，包含所有的依赖，包括 CoreRT，无需安装Framework
启动时是机器码，不需要生成机器码，也不要加载JIT编译器
可以使用其他优化编译器，包括 LLILC ,IL to CPP

CoreRT有两个方式生成机器码，第一个使用是直接编译IL成机器码，默认情况下，RyuJIT 作为一个 AOT 编译器将IL编译成机器码，另一个方式是将C#代码编译成C++代码，然后调用对应平台的C++编译器优化编译成机器码。

使用 RyuJIT 编译成机器码

dotnet restore

dotnet build --native --ilcpath <repo_root>\bin

\Product\Windows_NT.x64.Debug\packaging\publish1

编译生成 C++ 代码

dotnet restore

dotnet build --native --cpp --ilcpath <repo_root>\bin\Product\Windows_NT.x64.Debug\packaging\

publish1 --cppcompilerflags /MTd

CoreRT也有不足之处，它需要为不同平台编译一次；但凡事有但是，它允许工程师可以不发布到不想支持的平台（比如某游戏仅支持桌面，不支持手机）。

（4） CoreFX(.NET Core Libraries)

CoreFX主要包含数个公共库，例如 System.Collections, System.IO, System.Xml等。CoreFX是 .NET Standard Library 的实现，同样的.NET Framework 4.6.3也是基于.NET Standard Library的实现。它们目前都是基于.NET Standard Library1.6版本，具体见下表：

六、.NET Core 代码开发、部署、运行过程

从上图可以看到使用JIT编译和使用AOT编译源代码并运行程序是两种不同的流程。

如果使用JIT编译器部署程序时只需要将程序打包为IL的assemblies，在方法第一次执行前编译器将IL编译为目标机机器码(Native code)，而AOT编译会在编译时将源代码直接编译为目标机机器码。

AOT将源代码编译为机器码，拥有如下特性：

（1）用静态代码替换反射，例如如果一个值类型(value type)没有重写 ValueType.Equals 的equals的方法，默认情况判断相等，会使用反射找到filedinfo以确定type是否相等，然后再比较value是否相等。而在AOT编译中由于替换了反射因此只能比较value是否相等。

（2）依赖的第三方类库以及.NET Libraries均打包至最终编译的程序中。

（3）打包后的程序运行在一个精简版的运行时上(CoreRT)主要包含垃圾回收器，而运行时也会打包在app文件中。

（4）虽然编译时会替换反射代码，但遇动态反射代码无能为力，运行时若遇动态反射调用则会因找不到对应的元数据及实现而抛出异常。解决办法是编译前配置运行时指令文件(Runtime directive file)指定需要用到的程序集。

七，总结

主要介绍了.NET的三驾马车.NET Framework、.NET Core、Xamarin，.NET Framework是开发基于Windows平台的王者框架，而.NET Core的跨平台特性、开源及灵活的部署机制将是.NET的未来。

后面介绍了.NET Core的组成、.NET Core主要功能模块：应用层、中间层、编译器。最后简要介绍了.NET Core的开发、部署、运行流程。