.NET 5 - 下一代.NET

 　　不知不觉中微软已经计划推出了下一代的.NET了，咱们先来看一下新的.NET有包含什么

　　What's new in .NET 5?

 　　.NET 5将会引入新的APIs，运行时功能和新的语言特点。

• 在运行时体验中将有更多的选择性。
• 全部平台将提供Java 互操做性。
• 将会在多个操做系统提供支持 Objective-C 和 Swift 互操做性。
• CoreFX 将扩展为支持 .NET 的静态编译（ahead-of-time – AOT），更小的空间占用和对更多操做系统的支持。

 　　注意到这里的.NET Standard所处位置，这也是咱们在ASP.NET Core - 开篇这篇文章中阐述.NET Standard出现的意义所在。

　　.NET 5 = .NET Core vNext

　　首先须要明确的是，.NET 5是下一代的Core，即便它再也不使用Core命名，接着咱们已经熟悉的Core里面的内容是保留的，由于.NET 5是Core的延续，按照微软的计划，.NET 5是在2020年的10月份才有release版本出来，因此接下来咱们看到的版本仍是ASP.NET Core 3.x 系列

 

 　　为啥不继续用Core命名呢？从发展轨迹来看，Core的出现是由于微软但愿从本质上区分Framework， 这也确实从底层到使用都进行了很是大的更改，此次微软但愿清楚地传达， .NET 5 是 .NET 平台的将来，将其称为 .NET 5 是要让它成为微软发布过的最高版本。

　　Improving

 　　每一次的更新换代，确定是基于易用性和性能上的提高，咱们来看一下微软官方的一个基于.NET 5的改进：　

• 改进体验，在任何地方均可以使用 .NET 运行时和框架，并具备统一的运行时行为
• 充分利用 .NET Core、.NET Framework、Xamarin 和 Mono 来扩展 .NET 的功能。

　

　　运行时体验　　

　　Mono 是 .NET 跨平台实现的基石，它最初是以开源为目的来替代 .NET Framework 的，Mono 是用做 Xamarin 一部分的运行时。

　　CoreCLR 是做为 .NET Core 一部分的运行时。它主要用于支持云应用程序，包括 Microsoft 的最大服务，如今也用于 Windows 桌面，物联网和机器学习应用程序。

　　总而言之，.NET Core 和 Mono 运行时有许多类似之处（毕竟它们都是 .NET 运行时），但也有宝贵的独特功能。让选择所需的运行时体验成为多是很是有意义的。咱们正在使 CoreCLR 和 Mono 能够互相替换。咱们将使它像构建开关同样简单，以便在不一样的运行时选项之间进行选择。

　　高吞吐量和高生产率

　　最开始.NET 就依赖于JIT（即时编译器）将IL（中间语言）代码转换为机器代码，从那时微软就构建了业界领先的基于 JIT 的托管运行时。该运行时具备很是高的吞吐量，而且提高了开发体验，使编程变得快速而简单，这也是为何这么多人口中微软的低门槛：）

　　大多数 .NET 5 的默认体验将使用基于 JIT 的 CoreCLR 运行时。两个值得注意的例外是 iOS 和客户端 Blazor（web assembly），由于它们都须要 ahead-of-time (AOT) 原生编译。

　　更快的启动，更低的内存占用率

　　Mono 项目的集中了大部分精力在移动和游戏机上。该项目的一个关键功能是基于业界领先的 LLVM 编译器项目的 .NET AOT 编译器。AOT 编译的应用能够在较小的位置高效运行, 并在须要时交换吞吐量以进行启动。

　　Blazor 项目已经在使用 Mono AOT，这将是最先过渡到 .NET 5 的项目之一。

　　有两种类型的 AOT 解决方案:

• 须要 100% AOT 编译的解决方案。
• 大多数代码是 AOT 编译的解决方案, 但 JIT 或解释器可用于与 AOT 不友好的代码模式。

　　.NET Native 是微软用于 Windows UWP 应用程序的 AOT 编译器, 也就是上面的第一种 AOT 类型。随着第一种方案的实现, 微软限制了 .NET API 和可使用的功能，从这一经验中了解到, AOT 解决方案须要覆盖 .NET API 和模式的全部方面。

 

　　　原则和交叉体验

　　基于startup，吞吐量，内存占用， 可靠性和诊断性做为平台的总体风格是很是重要的，这也是微软专一的努力方向。在专一于吞吐和可靠性的同时，也更专一于startup 和 Mono AOT编译器的大小控制，这是很好的匹对，例如吞吐和可靠性，startup 和 大小控制。

　　微软将会持续在各类场景对.NET 5进行优化，特别是在具备多种交叉场景的状况下进行重点优化。

　　全部的 .NET 5应用将会使用CoreFX框架，微软将会确保在现在不常用的地方保证.NET 5的正常工做，这主要集中在Xamarin 和 客户端 Blazor的工做场景。还有.NET 5的应用在.NET CLI都是可构建的，只需确保在项目中有基于命令行的基础编译工具便可。

　　C#语言将会保持跟.NET 5的同步，开发者在后续开发.NET 5应用是将可以使用最新版本的C#以及对应的特性。

 　　

　　Birth of the project

　　微软于 2018 年 12 月在波士顿碰头后组建了技术团队并开始了这个项目。来自 .NET 团队（Mono/Xamarin和.NET Core）以及 Unity 的设计领导者介绍了各类技术和架构方向。

　　.NET 5这个项目目前是做为单个团队推动，并以提供一套可交付成果为导向。自 12 月以来，在如下一些项目上取得了较多的进展：

• 定义一个极小的分层用来定义运行时 <-> 托管代码层，目标是实现 >99% 的 CoreFX 公共代码。
• MonoVM 可使用 CoreFX 及其类库。
• 在 MonoVM 上使用CoreFX的实现运行全部 CoreFX 测试。
• 在 MonoVM 上运行 ASP.NET Core 3.0 应用程序。
• 在 CoreCLR 上运行 MonoDevelop，而后运行 Visual Studio for Mac。

　　迁移到单个.NET的实现会引起一些问题: 目标框架将是什么？ NuGet包兼容性规则是否相同？ .NET 5 SDK 应该支持哪些工做负载？特定框架的编码将如何工做？咱们还须要 .NET Standard吗？
　　好吧，让巨人先走，咱们慢慢爬上去吧：）

 　　Ending

　　.NET 5 是使人兴奋的新方向。微软此次的.NET更新换代，旨在让全部的人看到， .NET 将变得更简单，且具备更普遍功能和实用性。全部新的开发和功能都将成为 .NET 5 的一部分，包括新的 C# 版本，在使用相同的 .NET API 和语言来针对各类应用程序类型、操做系统和芯片架构将会使微软的发展有着更光明的将来，它可使咱们在 Visual Studio ，Visual Studio for Mac，Visual Studio Code，Azure DevOps 或命令行中轻松更改构建配置用于构建不一样的应用程序。