.NET 5.0

我们很高兴今天发布.NET5.0，并期待您开始使用它。这是一个重要的版本--包括C#9和F#5--具有广泛的新特性和引人注目的改进。它已经被微软和其他公司的团队在生产和性能测试中积极使用。这些团队向我们展示了出色的结果，展示了性能提升和/或降低其Web应用托管成本的机会。从预览版1开始，我们一直在5.0上运行我们自己的网站。从我们目前的所见所闻来看，.NET5.0无需太多的升级就能带来巨大的价值。对于你的下一款应用来说，这是一个很好的选择，而且可以直接从早期的.NET Core版本升级。我们希望您喜欢在台式机、笔记本电脑和云实例上使用它。

ASP.NET Core、EF Core、C#9和F#5也将在今天发布。Net Conf 2020-我们的免费虚拟会议-今天举行，让您了解所有新版本。

您可以下载.NET5.0，适用于Windows、MacOS和Linux，适用于x86、x64、Arm32和Arm64。

对于Visual Studio用户，您需要Visual Studio 16.8或更高版本才能在Windows上使用.NET 5.0，在MacOS上使用最新版本的Visual Studio for Mac)。Visual Studio代码的C#扩展已经支持.NET5.0和C#9。

NET 5.0是我们的.NET统一之旅的第一个版本。我们构建.NET5.0是为了让更多的开发人员能够将他们的.NET Framework代码和应用程序迁移到.NET5.0。我们在5.0中也做了很多早期工作，以便Xamarin开发人员在发布.NET6.0时可以使用统一的.NET平台。在后面的文章中会有更多关于.NET统一的内容。

现在是宣布与所有参与.NET项目的人进行令人难以置信的合作的好时机。这个版本标志着作为开源项目的第五个主要的.NET版本。现在，在GitHub上的DotNet org中，有大量的个人和大小公司(包括.NET Foundation企业赞助商)作为一个大型社区在.NET的各个方面共同工作。NET5.0中的改进是许多人、他们的努力、聪明的想法以及他们对该平台的关心和热爱的结果，所有这些都超出了微软对该项目的管理。从每天致力于.NET的核心团队，我们向所有为.NET5.0(以及之前的版本)做出贡献的人致以非常强烈的“感谢”！

我们早在2019年5月就引入了.NET5.0，当时甚至设定了2020年11月的发布日期。这篇帖子写道：“我们将在今年9月发布.NET Core 3.0，在2020年11月发布.NET5，然后我们打算每年11月发布一次.NET的主要版本。”你可能会认为“2020年11月”是一张支票，考虑到今年面临的所有挑战，这张支票是不能兑现的，然而，.NET5.0已经按时发布了。感谢团队中的每一个人，是他们让这一切成为现实！我知道这并不容易。展望未来，您应该可以期待在2021年11月发布.NET6.0。我们打算每年11月发布新的.NET版本。

博客的其余部分致力于突出和详细介绍.NET5.0中的大部分改进。还有一个关于我们的.NET统一愿景的更新。

.NET5.0已经在dot.net和Bing.com(版本)上托管了几个月，已经经过了战斗测试。

许多组件的性能都得到了极大的提高，在.NET5.0中的性能改进、.NET5.0中的ARM64性能和GRPC中都有详细描述。

C#9和F#5提供了新的语言改进，比如C#9的顶级程序和记录，而F#5提供了交互式编程和.NET上函数式编程的性能提升。

NET库增强了Json序列化、正则表达式和HTTP(HTTP 1.1、HTTP/2)的性能。它们现在也被完全注释为可为空。

由于GC、分层编译和其他方面的改进，P95延迟已经降低。

应用程序部署选项更好，ClickOnce客户端应用程序发布、单文件应用程序、减小的容器镜像大小以及添加的服务器核心容器镜像。

我已经为.NET5.0预览帖编写了很多样例。您可能想看一下.NET5.0示例，以了解更多关于新的C#9和库特性的信息。

对于Windows、MacOS和Linux，.Net 5.0的平台支持列表与.NET Core 3.1几乎相同。如果您在受支持的操作系统上使用.NET Core 3.1，则应该能够在该操作系统的大部分版本上采用.NET5.0。在.NET5.0中，最重要的新增功能是Windows Arm64。

.Net 5.0是当前版本。这意味着它将在.NET6.0发布后的三个月内得到支持。因此，我们预计到2022年2月中旬将支持.NET5.0。与.NET Core 3.1一样，.NET6.0将是一个LTS版本，并将支持三年。

去年，我们分享了一个统一的.NET堆栈和生态系统的愿景。它对您的价值在于，您将能够使用一组API、语言和工具来瞄准广泛的应用类型，包括移动、云、桌面和物联网。您可能已经意识到，现在您已经可以使用.NET面向广泛的平台，然而，工具和API在Web和Mobile之间并不总是相同的，或者并不总是同时发布的。

作为.NET5.0和6.0的一部分，我们正在将.NET统一到单一的产品体验中，同时使您能够选择您想要使用的.NET平台的部分。如果你想以Mobile而不是WebAssembly为目标，你不需要下载WebAssembly工具，反之亦然。ASP.NET Core和WPF也是如此。您还可以通过更简单的方式从命令行获取所需的所有.NET工具以及构建和运行时包。我们正在为.NET平台组件提供包管理器体验(包括使用现有的包管理器)。这对于很多场景来说都是很棒的。快速建设发展环境和传播与信息/光盘可能是最大的受益者。

我们原本打算用.NET5.0提供完整的统一愿景，但在全球流行之后，我们不得不适应客户不断变化的需求。我们一直在与来自世界各地的公司的团队合作，这些公司需要帮助来加快他们采用云技术的速度。他们也必须适应客户不断变化的需求。因此，我们将在两个版本中交付这一愿景。

实现这一愿景的第一步是整合.NET repos，包括Mono的一个大子集。拥有一个用于运行时和.NET库的repo是在任何地方交付相同产品的前提条件。它还有助于进行广泛的更改，这些更改会影响运行时和库，而这些库以前是有repo边界的。一些人担心，大规模回购将更难管理。事实证明并非如此。

在.NET5.0版本中，Blazor是利用回购整合和.NET统一的最佳例子。Blazor WebAssembly的运行时和库现在是从合并的DotNet/运行时repo构建的。例如，这意味着Blazor WebAssembly和服务器上的Blazor对List<；T>；使用完全相同的代码。但在.NET5.0之前，Blazor并非如此。我们对Blazor WebAssembly采取的方法与我们在.NET6.0中使用Xamarin的方法非常相似。

NET Framework仍然是受支持的Microsoft产品，并且每个新版本的Windows都将继续支持它。我们去年宣布已经停止向.NET Framework添加新功能，并完成了向.NET Core添加.NET Framework API。这意味着现在是考虑将您的.NET Framework应用程序迁移到.NET Core的大好时机。对于.NET Framework客户端开发人员，.NET5.0支持Windows窗体和WPF。我们从许多开发人员那里听说，从.NET Framework移植非常简单。对于.NET Framework服务器开发人员，您需要采用ASP.NET Core才能使用.NET5.0。对于Web Forms开发人员，我们相信Blazor通过更高效、更现代化的实现提供了类似的开发体验。WCF服务器和工作流用户可以查看支持这些框架的社区项目。从.NET Framework移植到.NET Core文档是一个很好的起点。这就是说，如果你对自己的体验满意，那么让你的应用程序运行在.NET Framework上是一个很好的方法。

Windows团队正致力于将留尼汪号项目作为UWP及其相关技术的下一步。我们一直在与留尼汪岛团队合作，以确保.NET5.0及更高版本能够很好地与WinUI和WebView2协同工作。团圆项目是了解最新进展的最佳场所。

让我们来看看5.0版本中的新特性。

C#9和F#5是.NET5.0版本的一部分，包含在.NET5.0SDK中。Visual Basic也包含在5.0 SDK中。它不包括语言更改，但进行了改进以支持.NET Core上的Visual Basic应用程序框架。

C#源代码生成器是一项重要的C#编译器新特性。从技术上讲，它们不是C#9的一部分，因为它没有任何语言语法。请参阅新的C#源代码生成器示例，帮助您开始使用这一新功能。我们希望在.NET6.0及更高版本的.NET产品中更多地使用源代码生成器。

作为自己试用新版本的一种方式，我们中的一些人决定更新DotNet/IoT Repo，以使用新的C#9语法并以.NET5.0为目标。它使用顶级程序、记录、模式和切换表达式。它还进行了更新，以利用.NET库中完整的可为空的批注集。我们将查看该repo中的几个示例来探索C#9。

Using System；Using System.Device.Gpio；Using System.Thread；var pin=18；var lightTime=1000；var dimTime=200；Console.WriteLine($"；让'；s闪烁LED！"；)；使用GpioController控制器=new()；Controller er.OpenPin(pin，PinMode.Output)；Console.WriteLine($"；GPIO pin已启用使用：控制器.Write(管脚，PinValue.High)；线程.睡眠(LightTime)；Console.WriteLine($"；调暗{dimTime}ms&34；)；控制器.Write(管脚，PinValue.Low)；线程.睡眠(DimTime)；}。

您还可以看到如何使用目标类型的new，并将其赋值给控制器变量。GpioController类型仅在赋值的左侧定义。类型是在右手边推断出来的。这种新语法是var的另一种选择，var的类型只显示在赋值的右侧，并通过关键字var在左侧推断。

通过定义方法并利用在相同或其他文件中定义的类型，顶级程序也可能增加复杂性。CharacterLcd示例演示了其中一些功能。

C#9包括对新模式的支持。您可以在CCS811气体传感器的以下代码中看到一个逻辑模式的示例。

另一种新模式是财产模式。您可以在我的Mycroft信息访问6.0示例中看到几个属性检查。以下代码摘自PN532 RFID和NFC读取器示例。

这段代码测试pollingType(类型为byte[])不为空，并且不包含>；15个字节。

C#9包括一种名为Record的新类。与常规类相比，它有许多好处，其中一半与更简洁的语法有关。以下记录取自Bh1745 RGB传感器绑定。

现在，.NET库完全为空性添加了注释。这意味着如果您启用了空性，您将从平台获得更多类型信息来指导您使用该功能。目前，还没有对.NET文档进行完整的注释。例如，String.IsNullOrEmpty(String)应该被注释为接受一个字符串？，而String.Split(Char[])的注释是char[]？我们希望这个问题很快就能解决。完整的信息可以在Soure.dot.net上找到，也可以通过Visual Studio中的F12元数据查找获得。

System.Device.Gpio和Iot.Device.Bindings包(这两个包的版本都是1.1.0)也作为此版本的一部分进行了注释，使用了更新的.NET5.0注释。这两个库都是多目标的，但是，我们使用5.0视图为所有目标生成注释。

注意：现有的.NET Core 3.1代码可能会在您将其重定目标为.NET5.0时生成新的诊断(如果您启用了为空功能)，因为有新的注释。

我们还添加了新的注释类型。大型类在从构造函数调用的帮助器方法中实例化对象成员是很常见的。C#编译器不能遵循对对象赋值的调用流程。当退出构造函数时，它会认为该成员为空，并将使用CS8618发出警告。MemberNotNull属性可以解决此问题。将该属性应用于帮助器方法。然后，编译器将看到您设置了此值，并意识到该方法是从构造函数调用的。MemberNotNullWhen类似。

您可以使用以下代码在BMxx80温度传感器中看到MemberNotNull的示例。

[MemberNotNull(nameof(_calibrationData))]private空读取校准数据(){Switch(This){case BME280_：_CalibrationData=new Bme280 CalibrationData()；_Control Register=(字节)Bmx280Register.CTRL_Meas；Break；case Bmp280_：_CalibrationData=new Bmp280 CalibrationData()；_Control Register=(字节)Bmx280Register.CTRL_Meas；Break；case BME6。找不到校准数据。"；)；}_CalibrationData.ReadFromDevice(This)；}。

实际代码使用条件编译。这是因为该项目是多目标的，而该属性仅在.NET5.0+中受支持。使用该属性可以跳过运行时检查(在构造函数中)，否则将需要这些检查来满足可空性要求，就像早期的.NET版本一样。

我们改进了Windows Forms Designer，更改了目标框架在.NET5.0及更高版本中的工作方式，更改了支持WinRT的方式，并进行了其他改进。

Windows窗体设计器(用于.NET Core 3.1和.NET5.0)已在Visual Studio 16.8中进行了更新，现在支持所有Windows窗体控件。它还支持所有的Telerik控件。设计器包括您预期的所有设计器功能，包括：拖放、选择、移动和调整大小、控件的剪切/复制/粘贴/删除、与属性窗口的集成、事件生成等。数据绑定和对更广泛的第三方控件集的支持很快就会到来。

在.NET5.0中，我们更改了用于目标框架的方法。以下项目文件演示了新的.NET5.0目标框架。

新的net5.0表单比我们之前使用的netcoreapp3.1样式更紧凑、更直观。此外，我们正在扩展目标框架以描述操作系统依赖关系。这一变化是由我们的愿景推动的，即在.NET6.0中支持使用Xamarin瞄准iOS和Android。

Windows桌面API(包括Windows窗体、WPF和WinRT)仅在面向net5.0-windows时可用。您可以指定操作系统版本，如net5.0-Windows7或net5.0-windows10.0.17763.0(适用于Windows 2018年10月更新)。如果您想要使用WinRT API，则需要瞄准Windows 10版本。

当使用新的net5.0-windows tfm时，跨平台的场景可能会更具挑战性。例如，System.Device.Gpio演示了一种用于管理Windows目标框架的模式，例如，如果您希望避免为Windows构建或避免在Linux上拉取Windows运行时包。

Net5.0-Windows将用于公开特定于Windows的功能，包括Windows Forms、WPF和WinRT API。

.Net 6.0将使用与net6.0相同的方法，并将添加net6.0-iOS和net6.0-android。

像ASP.NET Core这样的可移植API将可以在net5.0上使用。同样的情况也适用于Net6.0的Xamarin Forms。

Visual Studio 16.8中的模板仍然以.NET Core 3.1为目标，用于控制台、WPF和Windows窗体应用程序。ASP.NET模板已更新为支持.NET5.0。我们将在Visual Studio 16.9中更新其余模板的模板。

关于以Windows API为目标的主题，我们已经转向了一个新的模型，将WinRT API作为.NET5.0的一部分来支持。这包括调用API(双向；CLR<；==>；WinRT)，两个类型系统之间的数据封送处理，以及要在类型系统或ABI边界上被同等对待的类型的统一(例如，“投影类型”；IEnumerable<；T>；和IIterable<；T>；就是例子)。

现有的WinRT互操作系统已作为.NET5.0的一部分从.NET运行时中移除。这是一个突破性的变化。这意味着使用WinRT和.NET Core 3.x的应用程序和库需要重新构建，不能按原样在.NET5.0上运行。使用WinRT API的库需要多目标来管理.NET Core 3.1和.NET5.0之间的这种差异。

展望未来，我们将依靠WinRT团队在Windows中提供的新CsWinRT工具。它生成基于C#的WinRT互操作程序集，这些程序集可以通过NuGet交付。这正是Windows团队正在为Windows中的WinRT API所做的事情。任何想要使用WinRT(在Windows上)作为互操作系统的人都可以使用该工具，以将本机API公开给.NET或将.NETAPI公开给本机代码。

CsWinRT工具在逻辑上类似于tlbimp和tlbexp，但要好得多。TLB工具依赖于.NET运行时中的大量COM互操作管道。CsWinRT工具只依赖于公共的.NETAPI。也就是说，C#9中的函数指针功能--在.NET5.0运行时中部分实现了--在一定程度上是受到CsWinRT工具需求的启发。

它与为iOS和Android等其他操作系统提供的基于工具的互操作系统是对称的。

该工具可以利用其他.NET特性(AOT、C#特性、IL链接)，而这在以前的系统中不是一个选项。

使用WinRT API不需要添加NuGet引用。以Windows10TFM为目标--刚才在.NET5.0TFM一节中已经讨论过了--已经足够了。如果您的目标是.NET Core 3.1或更早版本，则需要引用WinRT包。您可以在System.Device.Gpio项目中看到此模式。

很长一段时间以来，我们一直要求为调用.NET代码的本机二进制文件启用导出。该场景的构建块是托管对UnManagedCeller sOnlyAttribute的API支持。

此功能是创建更高级别体验的构建块。我们团队中的Aaron Robinson一直致力于一个.NET Native Exports项目，该项目为将.NET组件发布为本机库提供了更完整的体验。我们正在寻找有关此功能的反馈，以帮助决定是否应将该方法包含在产品中。

多年来，我们在本机应用程序中看到了各种.NET托管模型。@rseanHall为此提出并实现了一种新颖的新模型，该模型利用了.NET应用程序托管层提供的所有内置应用程序功能(特别是加载依赖项)，同时允许从本机代码调用自定义入口点。这在很多情况下都是完美的，可以想象在从本机应用程序托管.NET组件的开发人员中变得流行起来。这在以前是不存在的。谢谢你的贡献，@rseanHall。

事件管道是我们在.NET Core 2.2中添加的一个新的子系统和API，它使执行性能和其他诊断成为可能。

.