微軟宣布.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 或命令行中，可以輕鬆更改構建配置以構建不同的應用程序。
英文原文：https://devblogs.microsoft.com/dotnet/introducing-net-5/