我们很高兴宣布.NET Core 3.1的发布。 实际上，这只是对我们两个多月前发布的
.NET Core 3.0的一小部分修复和完善。 最重要的功能是.NET Core 3.1是
长期支持（LTS）版本，并且将支持三年。 和过去一样，我们希望花一些时间来发布下一个LTS版本。 额外的两个月（在.NET Core 3.0之后）使我们能够选择和实施在已经非常稳定的基础上进行的正确改进。 .NET Core 3.1现在随时可以在您的想象力或业务需求需要的地方使用。
您可以
下载适用于Windows，macOS和Linux的
.NET Core 3.1 ：
ASP.NET Core和
EF Core也在今天发布。
Visual Studio 2019 16.4也于今天发布，其中包括.NET Core 3.1。 这是将.NET Core 3.1与Visual Studio一起使用所必需的更新。 对于Visual Studio 2019用户，我们建议仅将Visual Studio更新到16.4，而不是单独下载.NET Core 3.1。
Visual Studio for Mac在Visual Studio for Mac 8.4预览通道中还支持并包含.NET Core 3.1。 您需要选择使用Preview通道才能使用.NET Core 3.1。
发行说明：
.NET Core 3.1中的更改主要集中在
Blazor和
Windows Desktop ，这是.NET Core 3.0中的两个新增功能。 这包括对C ++ / CLI的支持，这是针对Windows的开发人员的常规要求。
在我们了解.NET Core 3.1的新功能之前，让我们快速了解一下
.NET Core 3.0的关键改进，这是.NET Core 3.1需要考虑的大部分重要内容。
.NET Core 3.0改进概述
.NET Core 3.0提供了以下关键改进。 我们已经从
大型网站的开发人员那里听说，它对他们来说效果很好。
- .NET Core 3.0已经在dot.net和Bing.com上托管了几个月，已经通过了测试。 许多其他Microsoft团队很快将在生产中的.NET Core 3.1上部署大型工作负载。
- 在许多组件中，性能都得到了极大的提高，并且在.NET Core 3.0中的性能改进和.NET Core中的 硬件固有中进行了详细描述。
- C＃8添加异步流，范围/索引， 更多模式和可为空的引用类型 。 Nullable使您可以直接针对导致
NullReferenceException代码缺陷。 框架库的最底层已添加了注释，以便您知道何时需要null 。 - F＃4.7致力于通过隐式
yield表达式和一些语法放松使某些事情变得容易。 它还包括对LangVersion支持，并随nameof一起nameof并在预览中打开静态类。 F＃核心库现在还针对.NET Standard 2.0。 您可以在发布F＃4.7中了解更多信息。 - .NET Standard 2.1增加了可在.NET Core和Xamarin都可以使用的代码中使用的类型集。 .NET Standard 2.1包括.NET Core 2.1以后的类型。
- .NET Core现在支持Windows窗体和WPF （和开源 ）的Windows桌面应用程序。 WPF设计器是Visual Studio 2019的一部分。WindowsForms设计器处于预览状态，可以下载。
- 现在，.NET Core应用程序默认情况下具有可执行文件。 在过去的发行版中，需要通过
dotnet命令启动应用程序，例如dotnet myapp.dll 。 现在，可以使用特定于应用程序的可执行文件（如./myapp或./myapp启动应用程序，具体取决于操作系统。 - 添加了高性能JSON API，用于读取器/写入器，对象模型和序列化方案。 这些API是在
SpanT基础上从头开始构建的，并且在SpanT使用UTF8而不是UTF16（例如string ）。 这些API最小化分配，从而提高了性能，并减少了垃圾收集器的工作。 请参阅尝试新的System.Text.Json API 。 - 默认情况下，垃圾收集器使用较少的内存，通常少得多。 对于许多应用程序托管在同一服务器上的情况，此改进非常有用。 垃圾收集器也进行了更新，以更好地利用64核以上的机器上的大量核。 请参阅在具有64个以上CPU的计算机上为GC更好地配置CPU配置 。
- .NET Core已针对Docker进行了强化，以使.NET应用程序在容器中可预测且有效地工作。 已将容器配置为有限的内存或CPU时，垃圾收集器和线程池已更新为更好地工作。 .NET Core泊坞窗映像较小，尤其是SDK映像。 请参阅： 在小型容器场景下 使用Server GC运行 第0部分 ， 在小型容器场景下 使用Server GC运行第1部分-GC堆的硬限制以及同时使用.NET和Docker-DockerCon 2019更新 。
- 现在支持Raspberry Pi和ARM芯片以支持IoT开发，包括使用远程Visual Studio调试器。 您可以使用新的GPIO API部署可监听传感器的应用程序，并在显示器上打印消息或图像。 ASP.NET可用于将数据公开为API或允许配置IoT设备的站点。
平台支援
以下操作系统支持.NET Core 3.1：
- 高山：3.10+
- Debian：9岁以上
- Ubuntu的：16.04 +
- Fedora：29岁以上
- RHEL：6岁以上
- openSUSE：15岁以上
- SUSE Enterprise Linux（SLES）：12 SP2 +
- macOS：10.13+
- Windows客户端：7、8.1、10（1607+）
- Windows Server：2012 R2 +
注意：Windows窗体和WPF应用程序仅在Windows上起作用并受支持。
芯片支持如下：
- Windows，macOS和Linux上的x64
- Windows上的x86
- Windows和Linux上的ARM32
- Linux上的ARM64（内核4.14+）
注意：请确保.NET Core 3.1 ARM64部署使用Linux内核4.14版本或更高版本。 例如，Ubuntu 18.04满足此要求，但16.04不满足。
Windows窗体控件删除
以下Windows窗体控件已从.NET Core 3.1中删除：
- 数据网格
- 工具列
- 上下文菜单
- 菜单
- Mainmenu
- 菜单项
早在2005年，.NET Framework 2.0中就用功能更强大的控件替换了这些控件。多年来，默认情况下，Visual Studio Designer工具箱中并未提供这些控件。 因此，我们决定删除这些控件，而只关注新控件。
建议使用以下替代产品：
是的，这是一个不幸的重大变化。 如果使用的是我们在应用程序中删除的控件，则会看到构建中断。 另外，如果在最新版本的.NET Core Windows窗体设计器中打开.NET Core 3.0应用程序，则在使用这些控件时会看到错误。
我们建议您将应用程序更新为.NET Core 3.1，然后移至其他控件。 更换控件是一个简单的过程，本质上是“查找并替换”。
首先，我们应该在发布.NET Core 3.0之前进行这些更改，对此我们表示赞同。 我们尝试避免过时的更改，甚至避免突破性更改，这使我们很痛苦。
随着我们进一步进入Windows Forms设计器项目，我们意识到这些控件与创建现代应用程序不符，并且永远不应该成为Windows Forms的.NET Core端口的一部分。 我们还看到，他们需要我们更多的时间来支持而不是合理的。
我们的目标是继续改进Windows窗体，以实现更高的DPI，可访问性和可靠性，并且需要后期更改才能使我们专注于交付。
C ++ /命令行
我们在Visual Studio 2019 16.4中添加了对创建可与.NET Core 3.0+一起使用的C ++ / CLI（又称为“托管C ++”）组件的支持。 您需要安装“带C ++的桌面开发”工作负载和“ C ++ / CLI支持”组件，才能使用C ++ / CLI。
该组件添加了几个可以使用的模板：
- CLR类库（.NET Core）
- CLR空项目（.NET Core）
如果找不到它们，只需在“新建项目”对话框中搜索它们。
C ++ / CLI仅在Windows上启用。 不能将目标为.NET Framework的C ++ / CLI组件与.NET Core一起使用，反之亦然。
闭幕
我们建议您尽快迁移到.NET Core 3.1。 这是一个很棒的版本（很大程度上归功于3.0），它对.NET Core的许多方面进行了改进。 这也是一个
长期支持（LTS）版本 ，将支持三年。
生命周期更新：
- 从今天（2020年3月3日）起，.NET Core 3.0的生命周期将终止。
- .NET Core 2.2的每个生命周期都将在12月23日结束。
- .NET Core 2.1的支持将一直持续到2021年8月（这也是LTS版本）。
建议阅读以下.NET Core帖子，以了解有关.NET Core 3.1和我们正在从事的其他项目的更多信息。
基本原理
台式机
ASP.NET
一般