.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/