重磅：.NET5来了，未来已至？

日前，微软宣布.NET Core 3.0 之后的下一个版本将是 .NET 5，这意味着在下一版本的发布中将直接跳过4。可以肯定的是，将来只会有一个.NET，这个.net便是与.net core的融合版本。

以下为译文：

今天，我们宣布 .NET Core 3.0 之后的下一个版本将是 .NET 5 。这将是 .NET 系列的下一个重要版本，您将能够使用它来开发 Windows，Linux，macOS，iOS，Android，tvOS，watchOS 和 WebAssembly 等。

我们将在 .NET 5 中引入新的 .NET API、运行时功能和语言功能。

从 .NET Core 项目开始，我们已经向平台添加了大约五万个 .NET Framework API。 .NET Core 3.0 弥补了 .NET Framework 4.8 的大部分剩余功能差距，支持 Windows Forms，WPF 和Entity Framework 6。 .NET 5 构建于此工作之上，利用 .NET Core 和 Mono 的最佳功能创建一个平台，您可以用于所有现代 .NET 代码。

我们打算在 2020 年 11 月发布 .NET 5，并在 2020 年上半年推出第一个预览版（已推出）。将在 Visual Studio 2019、Visual Studio for Mac 和 Visual Studio Code 的未来更新中支持它。

.NET 5 = .NET Core vNext

NET 5 是 .NET Core 的下一步。该项目旨在通过以下几个关键方式改进 .NET：

1.制造一个可在任何地方使用的 .NET 运行时和框架, 并具有统一的运行时行为和开发人员体验。

2.通过充分利用 .NET Core、.NET Framework、Xamarin 和 Mono 来扩展 .NET 的功能。

3.从单个代码库构建该产品，开发人员（ Microsoft 和社区）可以一起工作并一起扩展，从而改进所有方案。

这个新项目和方向是 .NET 的一个重要转折。使用 .NET 5，无论您正在构建哪种类型的应用程序，您的代码和项目文件都将是相同的。每个应用都可以访问相同的运行时、API 和语言功能。也包括几乎每天都在进行的 corefx 的性能改进。

您所喜欢 .NET Core 的所有内容将继续存在：

*在 GitHub 上开源和面向社区。

*跨平台实现。

*支持利用特定于平台的功能，例如 Windows 上的 Windows form 和 WPF 以及来自 Xamarin 的每个原生平台的原生绑定。

*高性能。

*并排安装。

*小型项目文件（SDK风格）。

*兼容命令行界面（CLI）。

*Visual Studio，Visual Studio for Mac 和 Visual Studio Code集成。

也有一些新的东西：

*您将有更多关于运行时体验的选择（更多内容见下文）。

*Java 互操作性将在所有平台上提供。

*多个操作系统将支持 Objective-C 和 Swift 互操作性。

*CoreFX 将扩展为支持 .NET 的静态编译（ahead-of-time – AOT），更小的空间占用和对更多操作系统的支持。

我们将在每年 11 月发布一次主要版本的 .NET：

我们跳过了版本 4，因为它会让熟悉 .NET Framework 的用户感到困惑，因为 .NET Framework 已经使用了很长时间的4.x系列。此外，我们希望清楚地传达 .NET 5 是 .NET 平台的未来。将其称为 .NET 5 使其成为我们发布过的最高版本。

我们也借此机会简化命名。我们认为如果只有一个.NET是最好的了，我们就不需要像 “Core” 这样的澄清术语。较短的名称是一种简化, 还传达了 .NET 5 具有统一的功能和行为的信息。当然如果您愿意也可以继续使用 “.NET Core” 这个名称。

运行时体验

Mono 是 .NET 的原始跨平台实现。它最初是作为 .NET Framework 的开源替代品，并随着 iPhone/iOS 和 Android设 备的普及而转变为针对移动设备。Mono 是用作 Xamarin 一部分的运行时。

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

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

以下部分描述了我们计划用于 .NET 5 的主要重心。它们为我们计划如何单独和共同发展这两个运行时提供了清晰的视角。

高吞吐量和高生产率

从一开始，.NET 就依赖于即时编译器（JIT）将中间语言（IL）代码转换为优化的机器代码。从那时起，我们构建了业界领先的基于 JIT 的托管运行时，该运行时具有非常高的吞吐量，并且还提高了开发人员体验，使编程变得快速而简单。

JIT 非常适合长期运行的云和客户端方案。他们能够生成针对特定机器配置的代码，包括特定的 CPU 指令。JIT 还可以在运行时重新生成方法，这一共让 JIT 更快速的技术，同时仍可选择生成高度优化的代码版本 (如果这成为经常使用的方法)。

我们努力使 ASP.NET Core 在 Techpower 基准测试上运行得更快, 这是 JIT 强大的力量和我们在 CoreCLR 上的投资的一个很好的例子。我们为容器强化 .NET Core 的努力也证明了运行时动态适应受限环境的能力。

开发人员工具是 JIT 非常棒的另一个好例子，例如 dotnet watch 工具或编辑并继续。工具通常需要在单个进程中多次编译和加载代码, 而无需重新启动, 并且需要非常快速地执行此操作。

使用 .NET Core 或 .NET Framework 的开发人员主要依赖于 JIT 。因此，这种体验应该是熟悉的。

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

快速启动，占用空间小，内存使用率低

Mono 项目的大部分精力都集中在移动和游戏机上。该项目的一个关键功能和结果是基于业界领先的 LLVM 编译器项目的 .NET AOT 编译器。Mono AOT 编译器允许将 .NET 代码内置到一个可以在计算机上运行的原生代码可执行文件中, 就像 C++ 代码一样。AOT 编译的应用可以在较小的位置高效运行, 并在需要时交换吞吐量以进行启动。

Blazor 项目已经在使用 Mono AOT。这将是最早过渡到 .NET 5 的项目之一。我们把它作为证明这个计划的方案之一。

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

*需要 100% AOT 编译的解决方案。

*大多数代码是 AOT 编译的解决方案, 但 JIT 或解释器可用于与 AOT 不友好的代码模式 (如泛型)。

Mono AOT 支持这两种情况。出于安全原因，苹果对 iOS 和一些游戏机需要第一种 AOT。第二种方法是更好的选择, 因为它提供了 AOT 的优点并且避免了一些缺点。

.NET Native 是我们用于 Windows UWP 应用程序的 AOT 编译器, 也是上面列出的第一种 AOT 类型的示例。在这个特定实现里, 我们限制了 .NET API 和您可以使用的功能。我们从这一经验中了解到, AOT 解决方案需要涵盖 .NET API 和模式的所有方面。

在 iOS、 web assembly 和一些游戏机里 AOT 编译仍需要。对于更需要快速启动或低占用空间的应用程序, 我们将使 AOT 编译成为一个选项。

该项目的诞生

我们于 2018 年 12 月在波士顿召开了一个技术团队，开始了这个项目。来自 .NET 团队（Mono/Xamarin和.NET Core）以及 Unity 的设计领导者介绍了各种技术能力和架构方向。

我们现在正在将这个项目作为一个团队推进，并提供一套可交付成果。自 12 月以来，我们在一些项目上取得了很多进展：

*定义了一个最小层，它定义了运行时 <-> 托管代码层，目标是实现 >99% 的 CoreFX 公共代码。

*MonoVM 现在可以使用 CoreFX 及其类库。

*使用 CoreFX 实现在 MonoVM 上运行所有 CoreFX 测试。

*使用 MonoVM 运行 ASP.NET Core 3.0 应用程序。

*在 CoreCLR 上运行 MonoDevelop，然后运行 Visual Studio for Mac。

迁移到单个.NET实现会引发一些重要问题: 目标框架将是什么？ NuGet包兼容性规则是否相同？ .NET 5 SDK 应该支持哪些工作负载？如何为特定架构编写代码？我们还需要 .NET Standard吗？

我们现在正在解决这些问题，很快将分享设计文档供您阅读并提供反馈。

最后

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