.NET Core3.1发布
我们很高兴宣布.NET Core 3.1的发布。实际上，这只是对我们两个多月前发布的.NET Core 3.0的一小部分修复和完善。最重要的是.NET Core 3.1是长期支持（LTS）版本，并且将支持三年。和过去一样，我们希望花一些时间来发布下一个LTS版本。额外的两个月（在.NET Core 3.0之后）使我们能够选择和实施在已经非常稳定的基础上进行的正确改进。
您可以下载适用于Windows，macOS和Linux的.NET Core 3.1：
- .NET Core 3.1 SDK和运行时
- Docker容器映像
- Snap安装程序
- 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发行说明
- .NET Core 3.1问题的GitHub问题
- GitHub发布
.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在预览中附带并打开了静态类。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，用于reader/writer，对象模型和序列化方案。这些API从头开始构建，Span并在幕后使用UTF8而不是UTF16（例如string）。这些API最小化分配，从而提高了性能，减少了垃圾收集器的工作。请参阅尝试新的System.Text.Json API。
- 默认情况下，垃圾收集器使用较少的内存，通常少得多。对于许多应用程序托管在同一服务器上的情况，此改进非常有用。垃圾收集器也进行了更新，以更好地利用64核以上的机器上的大量核。请参阅在具有64个以上CPU的计算机上为GC更好地配置CPU配置。
- .NET Core已针对Docker进行了强化，以使.NET应用程序在容器中可预测且有效地工作。已将容器配置为有限的内存或CPU时，垃圾收集器和线程池已更新为更好地工作。.NET Core Docker窗映像较小，尤其是SDK映像。请参阅：在小型容器场景中使用服务器GC运行第0部分，在小型容器场景中使用服务器GC运行第1部分-GC堆的硬限制以及同时使用.NET和Docker-DockerCon 2019更新。
- 现在支持Raspberry Pi和ARM芯片以支持IoT开发，包括使用远程Visual Studio调试器。您可以使用新的GPIO API部署可监听传感器的应用程序，并在显示器上打印消息或图像。ASP.NET可用于将数据公开为API或允许配置IoT设备的站点。
支持平台
以下操作系统支持.NET Core 3.1：
- Alpine: 3.9+
- Debian: 9+
- openSUSE: 42.3+
- Fedora: 26+
- Ubuntu: 16.04+
- RHEL: 6+
- SLES: 12+
- macOS: 10.13+
- Windows Client: 7, 8.1, 10 (1607+)
- Windows Server: 2012 R2 SP1+
注意：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中删除：
- 数据网格
- 工具栏
- 上下文菜单
- 菜单
- 主菜单
- 菜单项
早在2005年，这些控件就被.NET Framework 2.0中更强大的控件所取代。默认情况下，多年来，Visual Studio Designer工具箱中都没有提供这些控件。结果，我们决定删除这些控件，而只关注新控件。
建议使用以下替代产品：
旧控件（API）
建议更换
其他关联的API已删除
是的，这是一个不幸的重大变化。如果您使用的是我们在应用程序中删除的控件，则会看到构建中断。另外，如果在最新版本的.NET Core Windows窗体设计器中打开.NET Core 3.0应用程序，则在使用这些控件时会看到错误。
我们建议您将应用程序更新为.NET Core 3.1，然后移至其他控件。更换控件是一个简单的过程，本质上是“查找并替换”。
首先，我们应该在发布.NET Core 3.0之前进行这些更改，对此我们表示赞同。我们尝试避免过时的更改，甚至避免突破性更改，这使我们很痛苦。
随着我们进一步进入Windows Forms设计器项目，我们意识到这些控件与创建现代应用程序不符，并且永远不应该成为Windows Forms的.NET Core端口的一部分。我们还看到，他们需要我们更多的时间来支持而不是合理的。
我们的目标是继续改进Windows窗体，以实现更高的DPI，可访问性和可靠性，并且需要后期更改才能使我们专注于交付。
C ++ / CLI
我们在Visual Studio 2019 16.4中增加了对创建可与.NET Core 3.0+一起使用的C ++ / CLI（又称为“托管C ++”）组件的支持。您需要安装“带C ++的桌面开发”工作负载和“ C ++ / CLI支持”组件，才能使用C ++ / CLI。
该组件添加了几个可以使用的模板：
- CLR Class Library (.NET Core)
- CLR Empty Project (.NET Core)
如果找不到它们，只需在“新建项目”对话框中搜索它们。
C++ / CLI仅在Windows上启用。您不能将目标为.NET Framework的C ++ / CLI组件与.NET Core一起使用，反之亦然。
结束
我们建议您尽快迁移到.NET Core 3.1。这是一个很棒的版本（很大程度上是由于3.0），它对.NET Core的许多方面进行了改进。这也是一个长期支持（LTS）版本，将支持三年。
生命周期更新：
- .NET Core 3.0将于今天（到2020年3月3日）维护三个月。
- .NET Core 2.2的整个维护周期都将在12月23日结束。
- .NET Core 2.1的支持将一直持续到2021年8月（这也是LTS版本）。
来源：https://devblogs.microsoft.com/dotnet/announcing-net-core-3-1/
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持易盾网络。