.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 或命令行中轻松更改构建配置用于构建不同的应用程序。

转载于:https://www.cnblogs.com/lex-wu/p/10870052.html