去年年底，我們發佈了.NET Core 3.0和3.1。這些版本添加了桌面應用程序模型Windows窗體（WinForms）和WPF，用於構建單頁應用程序的ASP.NET Blazor和用於跨平臺，基於合消息傳遞的跨平臺gRPC。我們還添加了用於構建服務的模板，用於與gRPC進行通信的豐富的客戶端代碼生成，REST API服務等等。我們很高興看到.NET Core 3成為有史以來最快採用的.NET版本，而僅僅在去年，我們又獲得了100萬用戶。
我們還與這些版本進行了交流，以結束從.NET Framework移植應用程序模型的過程。藉助.NET Core 3，我們已經移植了所有最常用的應用程序模型，並引入了更新的跨平臺框架來替代我們未移植的框架。
當我們期待下一個主要版本.NET 5時，我們繼續將.NET統一到一個平臺中，並在.NET 5中包含.NET移動設備應用程序模型（Xamarin）。.NET5將包含ASP.NET core，Entity Framework Core, WinForms, WPF, Xamarin和ML.NET。整個平臺將首次為所有應用程序模型使用統一的BCL（基類庫）。擁有比.NET Core和.NET Framework都更高的版本5，這也清楚表明.NET 5是.NET的未來，它是用於構建任何類型的應用程序的單個統一平臺。
我們已經說過很多次了，但是我們將再次重申。.NET Core，然後是.NET 5，用來構建所有新應用程序。只要Windows本身被支持，.NET Framework仍將受支持。我們將繼續提供安全性和錯誤修復，並保持網絡和加密API的最新狀態。將較舊的應用程序保留在.NET Framework上將保持安全並受到支持。
安裝.NET 5.0 Preview 1
今天，我們將發佈.NET 5的第一個預覽版，該預覽版計劃於今年11月下旬在GA（一般可用性）中發佈。
- .NET 5.0預覽版1 SDK
- .NET 5.0預覽版1運行時
請參閱 .NET 5 Preview 1中的ASP.NET Core更新，以瞭解當今的ASP.NET Core版本。
預覽1首次包括對Windows ARM64的支持。今天的版本包括.NET Core運行時。我們希望Preview 2包含SDK（ASP.NET Core，但不包括WPF或Windows窗體）。稍後的預覽將包括WPF和Windows窗體。對Windows ARM64的支持也將反向移植到.NET Core 3.1。我們將在“預覽2”帖子中分享有關此信息的更多信息。
更新現有項目
您可以通過更新目標框架來更新現有項目，如下所示：
<code><targetframework>netcoreapp5.0/<targetframework>/<code>
.NET 5的高級目標
讓我重點介紹 .NET 5的一些高級目標：
- 統一的.NET SDK經驗： 單個BCL（基類庫）包含在所有.NET 5應用程序中。今天，Xamarin應用程序使用Mono BCL，但將轉向使用.NET Core BCL，從而改善了我們應用程序模型之間的兼容性。 移動開發（Xamarin）已集成到.NET 5中。這意味著.NET SDK將支持手機開發。例如，您可以使用“ dotnet new XamarinForms”創建移動應用程序。
- 支持多個平臺的本機應用程序：單設備項目，該項目支持可以使用這些平臺上支持的本機控件在多個設備（例如Window Desktop，Microsoft Duo（Android）和iOS）上運行的應用程序。
- 支持多種平臺的Web應用程序：單個Blazor項目，該項目支持可以在瀏覽器中，在移動設備上以及作為本機桌面應用程序（例如Windows 10x）運行的應用程序
- 雲原生應用程序：高性能，單個文件（.exe）<50MB微服務，並支持在本地和雲中構建多個項目（API，Web前端，容器）。
- 持續改進，例如：BCL中的算法更快，運行時中對容器的更好支持，對HTTP3的支持。
今天的第一個預覽尚未包含支持這些高級目標的所有工作，但我們將在未來的預覽中繼續宣佈更多功能。
Preview 1中的改進
Preview 1中有以下改進：
正則表達式性能改進
我們已對Regex引擎進行了重大改進。在我們嘗試過的許多表達式中，這些改進通常可以使吞吐量提高3-6倍，在某些情況下甚至可以提高更多。我們即將發佈一篇博客文章，其中將詳細介紹這些改進。
RyuJIT中代碼質量的改進
每個版本都對JIT生成的代碼進行了一系列性能改進。我們將這些類型的改進稱為“CQ”或代碼質量。在大多數情況下，這些改進也適用於為準備運行的圖像生成的代碼。
預覽1中有以下改進：
- 空檢查摺疊的改進 –在更多情況下，通過觀察證明不需要空檢查的更多模式，無需生成空檢查。
- 調優的通用子表達式評估（CSE） – JIT查找並摺疊僅需要評估一次的重複表達式（wiki）。
- 優化“ constant_string”長度 –優化此模式並將代碼摺疊為正確的整數值。
- JIT：在變體之前構建基本的塊pred列表 -重新排序JIT中的階段，以允許較早使用密鑰優化，從而導致更好的代碼質量和更少的後續階段工作，從而增加了JIT吞吐量（參考中的“TP” PR）。
裝配負載診斷已添加到事件管道
我們已將程序集加載信息添加到事件管道。這項改進是開始提供類似的診斷功能（與.NET Framework一起使用Fusion Log Viewer的一部分）的開始。現在，您可以使用dotnet-trace通過以下命令來收集此信息：
<code>dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4 --process-id [process ID]
/<code>
使用事件管道的跟蹤程序集加載中描述了工作流。您可以查看簡單測試應用程序的程序集加載信息。
事件管道事件探查器API
事件管道是我們在.NET Core 2.2中添加的新子系統和API，可以在任何操作系統上執行性能和其他診斷調查。在.NET 5.0中，事件管道已得到擴展，以使探查器能夠寫入事件管道事件。對於以前依靠ETW監視應用程序行為和性能的分析探查器，此方案至關重要。
GitHub回購合併
作為.NET 5版本的一部分，我們減少了用於構建和打包.NET的GitHub存儲庫的數量。回購邊界對項目的許多方面都具有重大影響，包括構建和問題管理。使用.NET Core 1.0，我們在ASP.NET，EF和.NET Core中擁有超過100個存儲庫。通過此最新版本，我們現在可以一方面計算主存儲庫。我們還將幾乎所有存儲庫都移到了dotnet組織。
查看新的合併倉庫：
- dotnet/runtime（以前是dotnet/corefx，dotnet/coreclr和dotnet/core-setup）
- dotnet/aspnetcore（在aspnet組織中有多個存儲庫）
- dotnet/sdk（以前是dotnet/sdk，dotnet/cli）
結束
我們希望您對.NET 5正在進行的工作感到興奮！為.NET 5做準備的最好方法是將所有.NET Core應用程序遷移到3.1-我們將使從.NET Core 3.1到.NET 5的過渡儘可能輕鬆。而且，如果您仍在.NET Framework上構建應用程序，請放心將這些應用程序放在.NET Framework上，但請考慮對所有新應用程序使用.NET Core 3.1。.NET有很多令人興奮的事情！
閱讀更多 非科班碼農 的文章
