今天，我們宣布 .NET Core 3.0 之后的下一個(gè)版本將是 .NET 5 。這將是 .NET 系列的下一個(gè)重要版本。
將來只會(huì)有一個(gè) .NET ，您將能夠使用它來開發(fā) Windows，Linux君珠，macOS，iOS娇斑，Android策添，tvOS，watchOS 和 WebAssembly 等等毫缆。
我們將在 .NET 5 中引入新的 .NET API唯竹、運(yùn)行時(shí)功能和語言功能。
從 .NET Core 項(xiàng)目開始苦丁，我們已經(jīng)向平臺(tái)添加了大約五萬個(gè) .NET Framework API浸颓。 .NET Core 3.0 彌補(bǔ)了 .NET Framework 4.8 的大部分剩余功能差距，支持 Windows Forms，WPF 和Entity Framework 6产上。 .NET 5 構(gòu)建于此工作之上棵磷，利用 .NET Core 和 Mono 的最佳功能創(chuàng)建一個(gè)平臺(tái)，您可以用于所有現(xiàn)代 .NET 代碼晋涣。
我們打算在 2020 年 11 月發(fā)布 .NET 5泽本，并在 2020 年上半年推出第一個(gè)預(yù)覽版。將在 Visual Studio 2019姻僧、Visual Studio for Mac 和 Visual Studio Code 的未來更新中支持它。
.NET 5 = .NET Core vNext
NET 5 是 .NET Core 的下一步蒲牧。該項(xiàng)目旨在通過以下幾個(gè)關(guān)鍵方式改進(jìn) .NET：
- 制造一個(gè)可在任何地方使用的 .NET 運(yùn)行時(shí)和框架, 并具有統(tǒng)一的運(yùn)行時(shí)行為和開發(fā)人員體驗(yàn)撇贺。
- 通過充分利用 .NET Core、.NET Framework冰抢、Xamarin 和 Mono 來擴(kuò)展 .NET 的功能松嘶。
- 從單個(gè)代碼庫(kù)構(gòu)建該產(chǎn)品，開發(fā)人員（ Microsoft 和社區(qū)）可以一起工作并一起擴(kuò)展挎扰，從而改進(jìn)所有方案翠订。
這個(gè)新項(xiàng)目和方向是 .NET 的一個(gè)重要轉(zhuǎn)折。使用 .NET 5遵倦，無論您正在構(gòu)建哪種類型的應(yīng)用程序尽超，您的代碼和項(xiàng)目文件都將是相同的。每個(gè)應(yīng)用都可以訪問相同的運(yùn)行時(shí)梧躺、API 和語言功能似谁。也包括幾乎每天都在進(jìn)行的 corefx 的性能改進(jìn)。
您所喜歡 .NET Core 的所有內(nèi)容將繼續(xù)存在：
- 在 GitHub 上開源和面向社區(qū)掠哥。
- 跨平臺(tái)實(shí)現(xiàn)巩踏。
- 支持利用特定于平臺(tái)的功能，例如 Windows 上的 Windows form 和 WPF 以及來自 Xamarin 的每個(gè)原生平臺(tái)的原生綁定续搀。
- 高性能塞琼。
- 并排安裝。
- 小型項(xiàng)目文件（SDK風(fēng)格）禁舷。
- 兼容命令行界面（CLI）彪杉。
- Visual Studio，Visual Studio for Mac 和 Visual Studio Code集成牵咙。
也有一些新的東西：
- 您將有更多關(guān)于運(yùn)行時(shí)體驗(yàn)的選擇（更多內(nèi)容見下文）在讶。
- Java 互操作性將在所有平臺(tái)上提供。
- 多個(gè)操作系統(tǒng)將支持 Objective-C 和 Swift 互操作性霜大。
- CoreFX 將擴(kuò)展為支持 .NET 的靜態(tài)編譯（ahead-of-time – AOT）构哺，更小的空間占用和對(duì)更多操作系統(tǒng)的支持。
我們將在今年 9 月發(fā)布 .NET Core 3.0，在 2020 年 11 月發(fā)布 .NET 5曙强，然后我們打算每年 11 月發(fā)布一次主要版本的 .NET：
我們跳過了版本 4残拐，因?yàn)樗鼤?huì)讓熟悉 .NET Framework 的用戶感到困惑，因?yàn)?.NET Framework 已經(jīng)使用了很長(zhǎng)時(shí)間的4.x系列碟嘴。此外溪食，我們希望清楚地傳達(dá) .NET 5 是 .NET 平臺(tái)的未來。將其稱為 .NET 5 使其成為我們發(fā)布過的最高版本娜扇。
我們也借此機(jī)會(huì)簡(jiǎn)化命名错沃。我們認(rèn)為如果只有一個(gè) .NET 是最好的了，我們就不需要像 “Core” 這樣的澄清術(shù)語雀瓢。較短的名稱是一種簡(jiǎn)化, 還傳達(dá)了 .NET 5 具有統(tǒng)一的功能和行為的信息枢析。當(dāng)然如果您愿意也可以繼續(xù)使用 “.NET Core” 這個(gè)名稱。
運(yùn)行時(shí)體驗(yàn)
Mono 是 .NET 的原始跨平臺(tái)實(shí)現(xiàn)刃麸。它最初是作為 .NET Framework 的開源替代品醒叁，并隨著 iPhone/iOS 和 Android設(shè) 備的普及而轉(zhuǎn)變?yōu)獒槍?duì)移動(dòng)設(shè)備。Mono 是用作 Xamarin 一部分的運(yùn)行時(shí)泊业。
CoreCLR 是用作 .NET Core 一部分的運(yùn)行時(shí)把沼。它主要用于支持云應(yīng)用程序，包括 Microsoft 的最大服務(wù)吁伺，現(xiàn)在也用于 Windows 桌面饮睬，物聯(lián)網(wǎng)和機(jī)器學(xué)習(xí)應(yīng)用程序。
總而言之篮奄，.NET Core 和 Mono 運(yùn)行時(shí)有許多相似之處（畢竟它們都是 .NE T運(yùn)行時(shí)）续捂，但也有寶貴的獨(dú)特功能。讓選擇所需的運(yùn)行時(shí)體驗(yàn)成為可能是非常有意義的宦搬。我們正在使 CoreCLR 和 Mono 可以互相替換牙瓢。我們將使它像構(gòu)建開關(guān)一樣簡(jiǎn)單，以便在不同的運(yùn)行時(shí)選項(xiàng)之間進(jìn)行選擇间校。
以下部分描述了我們計(jì)劃用于 .NET 5 的主要重心矾克。它們?yōu)槲覀冇?jì)劃如何單獨(dú)和共同發(fā)展這兩個(gè)運(yùn)行時(shí)提供了清晰的視角。
高吞吐量和高生產(chǎn)率
從一開始憔足，.NET 就依賴于即時(shí)編譯器（JIT）將中間語言（IL）代碼轉(zhuǎn)換為優(yōu)化的機(jī)器代碼胁附。從那時(shí)起，我們構(gòu)建了業(yè)界領(lǐng)先的基于 JIT 的托管運(yùn)行時(shí)滓彰，該運(yùn)行時(shí)具有非常高的吞吐量控妻，并且還提高了開發(fā)人員體驗(yàn)，使編程變得快速而簡(jiǎn)單揭绑。
JIT 非常適合長(zhǎng)期運(yùn)行的云和客戶端方案弓候。他們能夠生成針對(duì)特定機(jī)器配置的代碼郎哭，包括特定的 CPU 指令。JIT 還可以在運(yùn)行時(shí)重新生成方法菇存，這一共讓 JIT 更快速的技術(shù)夸研，同時(shí)仍可選擇生成高度優(yōu)化的代碼版本 (如果這成為經(jīng)常使用的方法)。
我們努力使 ASP.NET Core 在 Techpower 基準(zhǔn)測(cè)試上運(yùn)行得更快, 這是 JIT 強(qiáng)大的力量和我們?cè)?CoreCLR 上的投資的一個(gè)很好的例子依鸥。我們?yōu)?a target="_blank" rel="nofollow">容器強(qiáng)化 .NET Core的努力也證明了運(yùn)行時(shí)動(dòng)態(tài)適應(yīng)受限環(huán)境的能力亥至。
開發(fā)人員工具是 JIT 非常棒的另一個(gè)好例子，例如 dotnet watch 工具或編輯并繼續(xù)贱迟。工具通常需要在單個(gè)進(jìn)程中多次編譯和加載代碼, 而無需重新啟動(dòng), 并且需要非辰惆纾快速地執(zhí)行此操作。
使用 .NET Core 或 .NET Framework 的開發(fā)人員主要依賴于 JIT 衣吠。因此茶敏，這種體驗(yàn)應(yīng)該是熟悉的。
大多數(shù) .NET 5 工作場(chǎng)景的默認(rèn)體驗(yàn)將使用基于 JIT 的 CoreCLR 運(yùn)行時(shí)蒸播。兩個(gè)值得注意的例外是 iOS 和客戶端 Blazor（web assembly），因?yàn)樗鼈兌夹枰?ahead-of-time (AOT) 原生編譯萍肆。
快速啟動(dòng)袍榆，占用空間小，內(nèi)存使用率低
Mono 項(xiàng)目的大部分精力都集中在移動(dòng)和游戲機(jī)上塘揣。該項(xiàng)目的一個(gè)關(guān)鍵功能和結(jié)果是基于業(yè)界領(lǐng)先的 LLVM 編譯器項(xiàng)目的 .NET AOT 編譯器包雀。Mono AOT 編譯器允許將 .NET 代碼內(nèi)置到一個(gè)可以在計(jì)算機(jī)上運(yùn)行的原生代碼可執(zhí)行文件中, 就像 C++ 代碼一樣。AOT 編譯的應(yīng)用可以在較小的位置高效運(yùn)行, 并在需要時(shí)交換吞吐量以進(jìn)行啟動(dòng)亲铡。
Blavor 項(xiàng)目已經(jīng)在使用 Mono AOT才写。這將是最早過渡到 .NET 5 的項(xiàng)目之一。我們把它作為證明這個(gè)計(jì)劃的方案之一奖蔓。
有兩種類型的 AOT 解決方案:
- 需要 100% AOT 編譯的解決方案赞草。
- 大多數(shù)代碼是 AOT 編譯的解決方案, 但 JIT 或解釋器可用于與 AOT 不友好的代碼模式 (如泛型)。
Mono AOT 支持這兩種情況吆鹤。出于安全原因厨疙，蘋果對(duì) iOS 和一些游戲機(jī)需要第一種 AOT。第二種方法是更好的選擇, 因?yàn)樗峁┝?AOT 的優(yōu)點(diǎn)并且避免了一些缺點(diǎn)疑务。
.NET Native 是我們用于 Windows UWP 應(yīng)用程序的 AOT 編譯器, 也是上面列出的第一種 AOT 類型的示例沾凄。在這個(gè)特定實(shí)現(xiàn)里, 我們限制了 .NET API 和您可以使用的功能。我們從這一經(jīng)驗(yàn)中了解到, AOT 解決方案需要涵蓋 .NET API 和模式的所有方面知允。
在 iOS撒蟀、 web assembly 和一些游戲機(jī)里 AOT 編譯仍需要。對(duì)于更需要快速啟動(dòng)或低占用空間的應(yīng)用程序, 我們將使 AOT 編譯成為一個(gè)選項(xiàng)温鸽。
該項(xiàng)目的誕生
我們于 2018 年 12 月在波士頓召開了一個(gè)技術(shù)團(tuán)隊(duì)保屯，開始了這個(gè)項(xiàng)目。來自 .NET 團(tuán)隊(duì)（Mono/Xamarin和.NET Core）以及 Unity 的設(shè)計(jì)領(lǐng)導(dǎo)者介紹了各種技術(shù)能力和架構(gòu)方向。
我們現(xiàn)在正在將這個(gè)項(xiàng)目作為一個(gè)團(tuán)隊(duì)推進(jìn)配椭，并提供一套可交付成果虫溜。自 12 月以來，我們?cè)谝恍╉?xiàng)目上取得了很多進(jìn)展：
- 定義了一個(gè)最小層股缸，它定義了運(yùn)行時(shí) <-> 托管代碼層衡楞，目標(biāo)是實(shí)現(xiàn) >99% 的 CoreFX 公共代碼。
- MonoVM 現(xiàn)在可以使用 CoreFX 及其類庫(kù)敦姻。
- 使用 CoreFX 實(shí)現(xiàn)在 MonoVM 上運(yùn)行所有 CoreFX 測(cè)試瘾境。
- 使用 MonoVM 運(yùn)行 ASP.NET Core 3.0 應(yīng)用程序。
- 在 CoreCLR 上運(yùn)行 MonoDevelop镰惦，然后運(yùn)行 Visual Studio for Mac迷守。
遷移到單個(gè).NET實(shí)現(xiàn)會(huì)引發(fā)一些重要問題: 目標(biāo)框架將是什么？ NuGet包兼容性規(guī)則是否相同旺入？ .NET 5 SDK 應(yīng)該支持哪些工作負(fù)載兑凿？如何為特定架構(gòu)編寫代碼？我們還需要 .NET Standard嗎茵瘾？
我們現(xiàn)在正在解決這些問題礼华，很快將分享設(shè)計(jì)文檔供您閱讀并提供反饋。
尾聲
.NET 5 項(xiàng)目是 .NET 的重要且令人興奮的新方向拗秘。您將看到 .NET 變得更簡(jiǎn)單圣絮，但也具有更廣泛，更廣泛的功能和實(shí)用性雕旨。所有新的開發(fā)和功能都將成為 .NET 5 的一部分扮匠，包括新的 C# 版本。
我們看到了光明的未來凡涩，您可以使用相同的 .NET API 和語言來面向各種應(yīng)用程序類型棒搜、操作系統(tǒng)和芯片架構(gòu)。在 Visual Studio 活箕，Visual Studio for Mac帮非，Visual Studio Code，Azure DevOps 或命令行中讹蘑，可以輕松更改構(gòu)建配置以構(gòu)建不同的應(yīng)用程序末盔。
Memo
本文轉(zhuǎn)載至：https://www.cnblogs.com/Rwing/p/introducing-net-5.html
