【翻譯】.NET Core3.1發佈

.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工具箱中都沒有提供這些控制項。結果，我們決定刪除這些控制項，而只關註新控制項。

建議使用以下替代產品：

是的，這是一個不幸的重大變化。如果您使用的是我們在應用程式中刪除的控制項，則會看到構建中斷。另外，如果在最新版本的.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/