微軟宣布 .NET 5 計劃

　　英文原文：Introducing .NET 5
　　中文翻譯：微軟正式宣布 .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 5，無論您正在構建哪種類型的應用程序，您的代碼和項目文件都將是相同的。每個應用都可以訪問相同的運行時、API 和語言功能。也包括幾乎每天都在進行的 corefx 的性能改進。

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

　　也有一些新的東西：

　　我們將在今年 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 解決方案:

　　.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 月以來，我們在一些項目上取得了很多進展：

　　遷移到單個 .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 或命令行中，可以輕松更改構建配置以構建不同的應用程序。