Build 2019：微軟正式宣佈 .NET 5

今天，我們宣佈 .NET Core 3.0 之後的下一個版本將是 .NET 5 。這將是 .NET 系列的下一個重要版本。

將來只會有一個 .NET ，您將能夠使用它來開發 Windows，Linux，macOS，iOS，Android，tvOS，watchOS 和 WebAssembly 等等。

我們將在 .NET 5 中引入新的 .NET API、執行時功能和語言功能。

從 .NET Core 專案開始，我們已經向平臺添加了大約五萬個 .NET Framework API。 .NET Core 3.0 彌補了 .NET Framework 4.8 的大部分剩餘功能差距，支援 Windows Forms，WPF 和Entity Framework 6。 .NET 5 構建於此工作之上，利用 .NET Core 和 Mono 的最佳功能建立一個平臺，您可以用於所有現代 .NET 程式碼。

我們打算在 2020 年 11 月釋出 .NET 5，併在 2020 年上半年推出第一個預覽版。將在 Visual Studio 2019、Visual Studio for Mac 和 Visual Studio Code 的未來更新中支援它。

.NET 5 = .NET Core vNext

NET 5 是 .NET Core 的下一步。該專案旨在透過以下幾個關鍵方式改進 .NET：

• 製造一個可在任何地方使用的 .NET 執行時和框架, 並具有統一的執行時行為和開發人員體驗。
• 透過充分利用 .NET Core、.NET Framework、Xamarin 和 Mono 來擴充套件 .NET 的功能。
• 從單個程式碼庫構建該產品，開發人員（ Microsoft 和社群）可以一起工作並一起擴充套件，從而改進所有方案。

這個新專案和方向是 .NET 的一個重要轉折。使用 .NET 5，無論您正在構建哪種型別的應用程式，您的程式碼和專案檔案都將是相同的。每個應用都可以訪問相同的執行時、API 和語言功能。也包括幾乎每天都在進行的 corefx 的效能改進。

您所喜歡 .NET Core 的所有內容將繼續存在：

• 在 GitHub 上開源和麵向社群。
• 跨平臺實現。
• 支援利用特定於平臺的功能，例如 Windows 上的 Windows form 和 WPF 以及來自 Xamarin 的每個原生平臺的原生系結。
• 高效能。
• 併排安裝。
• 小型專案檔案（SDK風格）。
• 相容命令列介面（CLI）。
• Visual Studio，Visual Studio for Mac 和 Visual Studio Code整合。

也有一些新的東西：

• 您將有更多關於執行時體驗的選擇（更多內容見下文）。
• Java 互操作性將在所有平臺上提供。
• 多個作業系統將支援 Objective-C 和 Swift 互操作性。
• CoreFX 將擴充套件為支援 .NET 的靜態編譯（ahead-of-time – AOT），更小的空間佔用和對更多作業系統的支援。

我們將在今年 9 月釋出 .NET Core 3.0，在 2020 年 11 月釋出 .NET 5，然後我們打算每年 11 月釋出一次主要版本的 .NET：

我們跳過了版本 4，因為它會讓熟悉 .NET Framework 的使用者感到困惑，因為 .NET Framework 已經使用了很長時間的4.x系列。此外，我們希望清楚地傳達 .NET 5 是 .NET 平臺的未來。將其稱為 .NET 5 使其成為我們釋出過的最高版本。

我們也藉此機會簡化命名。我們認為如果只有一個 .NET 是最好的了，我們就不需要像 “Core” 這樣的澄清術語。較短的名稱是一種簡化, 還傳達了 .NET 5 具有統一的功能和行為的資訊。當然如果您願意也可以繼續使用 “.NET Core” 這個名稱。

執行時體驗

Mono 是 .NET 的原始跨平臺實現。它最初是作為 .NET Framework 的開源替代品，並隨著 iPhone/iOS 和 Android設 備的普及而轉變為針對移動裝置。Mono 是用作 Xamarin 一部分的執行時。

CoreCLR 是用作 .NET Core 一部分的執行時。它主要用於支援雲應用程式，包括 Microsoft 的最大服務，現在也用於 Windows 桌面，物聯網和機器學習應用程式。

總而言之，.NET Core 和 Mono 執行時有許多相似之處（畢竟它們都是 .NE T執行時），但也有寶貴的獨特功能。讓選擇所需的執行時體驗成為可能是非常有意義的。我們正在使 CoreCLR 和 Mono 可以互相替換。我們將使它像構建開關一樣簡單，以便在不同的執行時選項之間進行選擇。

以下部分描述了我們計劃用於 .NET 5 的主要重心。它們為我們計劃如何單獨和共同發展這兩個執行時提供了清晰的視角。

高吞吐量和高生產率

從一開始，.NET 就依賴於即時編譯器（JIT）將中間語言（IL）程式碼轉換為最佳化的機器程式碼。從那時起，我們構建了業界領先的基於 JIT 的託管執行時，該執行時具有非常高的吞吐量，並且還提高了開發人員體驗，使程式設計變得快速而簡單。

JIT 非常適合長期執行的雲和客戶端方案。他們能夠生成針對特定機器配置的程式碼，包括特定的 CPU 指令。JIT 還可以在執行時重新生成方法，這一共讓 JIT 更快速的技術，同時仍可選擇生成高度最佳化的程式碼版本 (如果這成為經常使用的方法)。

我們努力使 ASP.NET Core 在 Techpower 基準測試上執行得更快, 這是 JIT 強大的力量和我們在 CoreCLR 上的投資的一個很好的例子。我們為容器強化 .NET Core的努力也證明瞭執行時動態適應受限環境的能力。

開發人員工具是 JIT 非常棒的另一個好例子，例如 dotnet watch 工具或編輯並繼續。工具通常需要在單個行程中多次編譯和載入程式碼, 而無需重新啟動, 並且需要非常快速地執行此操作。

使用 .NET Core 或 .NET Framework 的開發人員主要依賴於 JIT 。因此，這種體驗應該是熟悉的。

大多數 .NET 5 工作場景的預設體驗將使用基於 JIT 的 CoreCLR 執行時。兩個值得註意的例外是 iOS 和客戶端 Blazor（web assembly），因為它們都需要 ahead-of-time (AOT) 原生編譯。

快速啟動，佔用空間小，記憶體使用率低

Mono 專案的大部分精力都集中在移動和遊戲機上。該專案的一個關鍵功能和結果是基於業界領先的 LLVM 編譯器專案的 .NET AOT 編譯器。Mono AOT 編譯器允許將 .NET 程式碼內建到一個可以在計算機上執行的原生程式碼可執行檔案中, 就像 C++ 程式碼一樣。AOT 編譯的應用可以在較小的位置高效執行, 併在需要時交換吞吐量以進行啟動。

Blavor 專案已經在使用 Mono AOT。這將是最早過渡到 .NET 5 的專案之一。我們把它作為證明這個計劃的方案之一。

有兩種型別的 AOT 解決方案:

• 需要 100% AOT 編譯的解決方案。
• 大多數程式碼是 AOT 編譯的解決方案, 但 JIT 或直譯器可用於與 AOT 不友好的程式碼樣式 (如泛型)。
  Mono AOT 支援這兩種情況。出於安全原因，蘋果對 iOS 和一些遊戲機需要第一種 AOT。第二種方法是更好的選擇, 因為它提供了 AOT 的優點並且避免了一些缺點。

.NET Native 是我們用於 Windows UWP 應用程式的 AOT 編譯器, 也是上面列出的第一種 AOT 型別的示例。在這個特定實現裡, 我們限制了 .NET API 和您可以使用的功能。我們從這一經驗中瞭解到, AOT 解決方案需要涵蓋 .NET API 和樣式的所有方面。

在 iOS、 web assembly 和一些遊戲機裡 AOT 編譯仍需要。對於更需要快速啟動或低佔用空間的應用程式, 我們將使 AOT 編譯成為一個選項。

該專案的誕生

我們於 2018 年 12 月在波士頓召開了一個技術團隊，開始了這個專案。來自 .NET 團隊（Mono/Xamarin和.NET Core）以及 Unity 的設計領導者介紹了各種技術能力和架構方向。

我們現在正在將這個專案作為一個團隊推進，並提供一套可交付成果。自 12 月以來，我們在一些專案上取得了很多進展：

• 定義了一個最小層，它定義了執行時 託管程式碼層，標的是實現 >99% 的 CoreFX 公共程式碼。
• MonoVM 現在可以使用 CoreFX 及其類庫。
• 使用 CoreFX 實現在 MonoVM 上執行所有 CoreFX 測試。
• 使用 MonoVM 執行 ASP.NET Core 3.0 應用程式。
• 在 CoreCLR 上執行 MonoDevelop，然後執行 Visual Studio for Mac。

遷移到單個.NET實現會引發一些重要問題: 標的框架將是什麼？ NuGet包相容性規則是否相同？ .NET 5 SDK 應該支援哪些工作負載？如何為特定架構編寫程式碼？我們還需要 .NET Standard嗎？
我們現在正在解決這些問題，很快將分享設計檔案供您閱讀並提供反饋。

尾聲

.NET 5 專案是 .NET 的重要且令人興奮的新方向。您將看到 .NET 變得更簡單，但也具有更廣泛，更廣泛的功能和實用性。所有新的開發和功能都將成為 .NET 5 的一部分，包括新的 C# 版本。

我們看到了光明的未來，您可以使用相同的 .NET API 和語言來面向各種應用程式型別、作業系統和晶片架構。在 Visual Studio ，Visual Studio for Mac，Visual Studio Code，Azure DevOps 或命令列中，可以輕鬆更改構建配置以構建不同的應用程式。