今天,我们宣布.NET Core 3.0之后的下一个版本将是.NET 5.这将是.NET系列的下一个重要版本。
将来只有一个.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的下一步。该项目旨在通过以下几个关键方式改进.NET:
这个新项目和方向是.NET的游戏规则改变者。使用.NET 5,无论您正在构建哪种类型的应用程序,您的代码和项目文件都将看起来和感觉相同。您可以使用每个应用程序访问相同的运行时,API和语言功能。这包括几乎每天都致力于corefx的新性能。
您喜欢.NET Core的所有内容将继续存在:
这是新的东西:
我们将在今年9月发布.NET Core 3.0,在2020年11月发布.NET 5,然后我们打算每年11月每年发布一次主要版本的.NET:
我们正在跳过版本4,因为它会让熟悉.NET Framework的用户感到困惑,因为.NET Framework已经使用了很长时间的4.x系列。此外,我们希望清楚地传达.NET 5是.NET平台的未来。
我们也借此机会简化命名。我们认为如果前进只有一个.NET,我们就不需要像“核心”这样的澄清术语。较短的名称是简化,并且还传达.NET 5具有统一的功能和行为。如果您愿意,可以继续使用“.NET Core”名称。
Mono是.NET的原始跨平台实现。它起初是.NET Framework的开源替代品,随着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,同时如果这成为常用方法,仍然可以选择生成高度调整的代码版本。
我们在TechEmpower基准测试中使ASP.NET Core运行速度更快的努力是JIT的强大功能和我们在CoreCLR上投资的一个很好的例子。我们为容器强化.NET Core的努力也证明了运行时能够动态适应受约束的环境。
开发人员工具是JIT闪耀的另一个好例子,例如使用dotnet watch
工具或编辑并继续。工具通常需要在一个进程中多次编译和加载代码而无需重新启动,并且需要非常快速地完成。
使用.NET Core或.NET Framework的开发人员主要依赖于JIT。因此,这种体验应该是熟悉的。
大多数.NET 5工作负载的默认体验将使用基于JIT的CoreCLR运行时。两个值得注意的例外是iOS和客户端Blazor(Web程序集),因为它们都需要提前(AOT)本机编译。
Mono Project的大部分精力都集中在移动和游戏控制台上。该项目的关键功能和成果是基于行业领先的LLVM编译器项目的 .NET AOT编译器。Mono AOT编译器使.NET代码可以构建到可以在机器上运行的单个本机代码可执行文件中,就像C ++代码一样。AOT编译的应用程序可以在小地方高效运行,并在需要时交换吞吐量以进行启动。
该Blazor项目已在使用单声道AOT。它将是第一个转换到.NET 5的项目之一。我们将其作为一个场景来证明这个计划。
有两种类型的AOT解决方案:
Mono AOT支持这两种情况。Apple for iOS和某些游戏控制台需要第一种类型的AOT,通常是出于安全考虑。第二种是首选,因为它提供了AOT的优点而没有任何缺点。
.NET Native是我们用于Windows UWP应用程序的AOT编译器,是上面列出的第一种AOT类型的示例。通过该特定实现,我们限制了您可以使用的.NET API和功能。我们从该经验中了解到,AOT解决方案需要涵盖所有.NET API和模式。
iOS,Web程序集和一些游戏控制台仍然需要AOT编译。我们将AOT编译作为更像设备的应用程序的选项,需要快速启动和/或低占用空间。
至关重要的是,我们作为一个具有启动,吞吐量,内存使用,可靠性和诊断的整体平台继续向前发展。与此同时,集中精力也是有道理的。我们将在CoreCLR中投入更多的吞吐量和可靠性,同时我们使用Mono AOT编译器在启动和缩小尺寸方面投入更多资金。我们认为这些都是很好的配对。通过启动和减小尺寸,吞吐量和可靠性一起使用。
虽然有一些特征使得进行不同的投资是有意义的,但还有一些则没有。
对于功能和性能诊断,诊断功能在.NET 5中必须相同。支持相同的芯片和操作系统(iOS和Web组件除外)也很重要。
我们将继续为每个工作负载和场景优化.NET 5,无论有什么意义。将更加强调优化,特别是在多个工作负载具有重叠需求的情况下。
所有.NET 5应用程序都将使用CoreFX框架。我们将确保CoreFX在当前未使用的地方运行良好,主要是Xamarin和客户端Blazor工作负载。
所有.NET 5应用程序都可以使用.NET CLI构建,确保您跨项目使用通用命令行工具。
C#将与.NET 5一起向前发展。编写.NET 5应用程序的开发人员可以访问最新的C#版本和功能。
我们于2018年12月在波士顿召开了一个技术团队,开始了这个项目。来自.NET团队(Mono / Xamarin和.NET Core)以及Unity的设计领导者介绍了各种技术能力和架构方向。
我们现在正在将这个项目作为一个团队推进,并提供一套可交付成果。自12月以来,我们在一些项目上取得了很多进展:
转向单个.NET实现会引发重要问题。目标框架将是什么?NuGet包兼容性规则是否相同?.NET 5 SDK应该支持哪些工作负载?如何为特定架构编写代码?我们还需要.NET标准吗?我们现在正在解决这些问题,很快将分享设计文档供您阅读并提供反馈。
.NET 5项目是.NET的重要且令人兴奋的新方向。您将看到.NET变得更简单,但也具有更广泛,更广泛的功能和实用性。所有新的开发和功能都将成为.NET 5的一部分,包括新的C#版本。
我们看到前景光明,您可以使用相同的.NET API和语言来定位各种应用程序类型,操作系统和芯片架构。在Visual Studio,Visual Studio for Mac,Visual Studio代码,Azure DevOps或命令行中,可以轻松更改构建配置以构建不同的应用程序。
英文原文:https://devblogs.microsoft.com/dotnet/introducing-net-5/
来源:https://www.lpjnote.com/115.html