.NET Core 3.0 是 .NET Core 平臺的下一主要版本。本文回顧了 .Net Core 發展歷史，並展示了它是如何從基本支援 Web 和資料工作負載的版本 1，發展成為能夠執行 Web、桌面、機器學習、容器、IoT 等的版本 3.0。

.NET Core 1

.NET Core 的歷史可追溯到幾年前，版本 1 是在 2016 年推出，旨在生成第一版開放原始碼和跨平臺（Windows、macOS 和 Linux）的 .NET。靈感來源於只能使用開放原始碼框架的客戶，以及需要在 Linux 伺服器上執行 .NET 應用程式的其他客戶。由於 .NET Core 是跨平臺的，因此根據設計，可使用命令列完成所有操作，而無需使用 IDE。為了應對全域性安裝的 .NET Framework 的相容性挑戰，它設計有並行支援，包括隨附作為應用程式一部分的框架，這樣應用程式就不會依賴在計算機上安裝的任何框架。版本 1 隨附新版 ASP.NET、物體框架 (EF) 和主要定標的到的 Web 應用程式。

.NET Core 2

雖然版本 1 支援在新平臺上執行 .NET，但它僅支援一組數量有限的 .NET API。為瞭解決此問題，我們建立了 .NET Standard，它指定了任何 .NET 執行時必須實現的 API，這樣就能跨 .NET 平臺和版本共享程式碼和二進位制檔案了。在 .NET Standard 2.0 中，我們向 .NET Standard 規範添加了超過 20,000 個 API。.NET Core 版本 2 於 2017 年 6 月釋出，並支援 .NET Standard 2.0，使其有權訪問這些 API。我們還引入了 Windows 相容性包，這是包含許多僅 Windows API（如 System.Drawing、System.DirectoryServices 等）的 NuGet 包。ASP.NET Core 2.0 引入了 .NET Core 1.0 中缺少的兩個框架，即 Razor Pages 和 SignalR。Entity Framework Core 開始支援延遲載入，這是一項熱門物體框架功能。.NET Core 2 還在不斷推動 .NET 成為最快的完整堆疊框架之一。TechEmpower 基準由一家獨立公司執行，將 .NET Core 列為原始純文字效能領域的第 7 名，並將它列為 Web 和資料效能 Fortunes 測試中的第 6 名，擊敗了 Java servlet 和 Node.js (bit.ly/2PEE1l1)。

.NET Core 3.0

.NET Core 3.0 是 .NET Core 平臺的下一主要版本。它新增了許多令人興奮的功能，如支援使用 Windows 窗體 (WinForms)、Windows Presentation Foundation (WPF) 和物體框架 6 的 Windows 桌面應用程式。對於 Web 開發，它開始支援使用 C# 透過 Razor 元件（舊稱為 Blazor）生成客戶端 Web 應用程式。此外，它還支援 C# 8.0 和 .NET Standard 2.1。

我們正在 .NET Core 3.0. 中新增對物聯網 (IoT) 方案的支援。現在可以在 Raspberry Pi 和類似裝置上對硬體插針（用於控制裝置和讀取感測器資料）進行程式設計，併在所有受支援的 OS 上（例如，使用 Raspberry Pi 或 Arduino）透過串列埠進行通訊。我們還在此版本中添加了適用於 ARM64 的 IoT 裝置支援，以補充現有 ARM32 功能。

.NET Core 3.0 還將完全支援 ML.NET，這是為 .NET 開發人員生成的開放原始碼機器學習框架。ML.NET 強力驅動 Azure 機器學習、Windows Defender 和 PowerPoint Design Ideas 等產品。使用 ML.NET，可以將許多常用機器學習方案新增到應用中，如情緒分析、建議、預測、影象分類等。若要瞭解詳細資訊，請訪問 bit.ly/2OLRGRQ。

我們最近釋出了 .NET Core 3.0 的首個預覽版。若要詳細瞭解 .NET Core 3.0 和試用預覽版，請訪問 aka.ms/netcore3preview1。

桌面（WinForms 和 WPF）和開放原始碼

WinForms 和 WPF 是兩個最常用的 .NET 應用程式型別，有數百萬開發人員在使用。.NET Core 3.0 開始支援 WinForms 和 WPF，將 Windows 桌面開發引入了 .NET Core。.NET Core 一直以來都是開放原始碼的，在 GitHub 中這兩個框架與剩餘的 .NET Core 一樣，也都是開放原始碼的。客戶將有史以來第一次能夠見證這些框架的開放開發，甚至可以透過提問、修複 bug 或幫助在 GitHub 中實時開發新功能，從而提供幫助。WinUI XAML 庫也將是開放原始碼的。透過 XAML Islands，可以在 WinForms 和 WPF 應用程式中使用這些控制元件。

許多現有 WinForms 和 WPF 應用程式都使用物體框架來訪問資料，因此 .NET Core 也支援物體框架 6。

你可能想要知道，為什麼要在 .NET Core 上生成桌面應用程式。很簡單：這樣才能受益於 .NET Core 中的所有增強功能。不僅可以在最新版框架上生成應用程式，而無需安裝 .NET Core，還能將應用程式和 .NET Core 釋出到一個 .EXE 中。.NET Core 在設計時考慮到了並行支援，因此可以在一臺計算機上安裝多個版本，並能將應用程式鎖定到設計時定標的到的版本。此外，鑒於這種並行本質，可以改進 .NET Core 中的 API（包括 WinForms 和 WPF），而無需承擔損壞應用程式的風險。

ASP.NET Core 3

不過，.NET Core 3.0 並不都是與桌面相關。還有許多令人興奮的新功能是針對 Web 設計的。接下來將介紹我們正在開發的幾項功能。

客戶經常問的一個問題是，如何在 .NET Core 中獲得 RPC 體驗（就像在 .NET 遠端和 Windows Communication Foundation 中一樣）。我們正在參與 gRPC (grpc.io) 專案，以確保 gRPC 能夠為 .NET 開發人員提供一流支援。

在今年早些時候，我們開始了一項試驗，即使用 .NET（我們稱之為 Blazor）進行客戶端 Web 開發。藉助 Blazor，可以編寫直接在瀏覽器中的基於 WebAssembly 的 .NET 執行時內執行的 Web UI 元件，而無需編寫一行 JavaScript。使用 Razor 語法創作元件，這些元件與程式碼一起被編譯到常規 .NET 程式集中。然後，程式集和基於 WebAssembly 的 .NET 執行時被下載到瀏覽器中，僅使用開放式 Web 標準就能執行它們（無需任何外掛或程式碼轉換），如圖 1 所示。

圖 1：使用 Blazor 進行客戶端 Web 開發

也可以使用 .NET Core 在伺服器上執行相同元件，其中所有 UI 互動和 DOM 更新都是透過 SignalR 連線進行處理，如圖 2 所示。執行後，元件跟蹤 DOM 所需的更新，並透過 SignalR 連線將要應用的這些更新傳送到瀏覽器。UI 事件使用同一連線傳送到伺服器。此模型的優點有多個：下載大小更小、程式碼集中在伺服器上，以及受益於在 .NET Core 上執行元件的所有功能和效能優勢。

圖 2：使用 SignalR 在伺服器上執行 UI Web 元件

對於 .NET Core 3.0，我們將把 Blazor 元件模型整合到 ASP.NET Core 中。我們將此整合元件模型稱為“Razor 元件”。Razor 元件開啟了以下新時代：使用 ASP.NET Core 的可組合 UI，以及使用 .NET 的完整堆疊 Web 開發。對於 .NET Core 3.0，Razor 元件最初作為獨立可路由元件，或透過 Razor Pages 和檢視使用的元件在伺服器上執行。不過，相同元件也可以在 WebAssembly 上進行客戶端執行。在開發 .NET Core 3.0 的同時，我們還將繼續著手以下工作：支援使用基於直譯器的 .NET 執行時在 WebAssembly 上執行 Razor 元件，預計將在後續版本中提供。之後，我們還計劃向 WebAssembly 釋出對 .NET 程式碼的完全預編譯支援，這將顯著提升執行時效能。

EF Core 3.0

LINQ 是一項使用者鐘愛的 .NET 功能，可便於編寫資料庫查詢，而無需離開所選的語言，同時還能利用豐富的型別資訊來獲取 IntelliSense 和編譯時型別檢查。不過，LINQ 也支援編寫數量幾乎不限的複雜查詢，而這對於 LINQ 提供程式來說，一直都是一項巨大挑戰。EF Core 部分解決了此問題，具體方法是支援選擇可轉換為 SQL 的查詢部分，再執行記憶體中剩餘的查詢。在某些情況下，這樣做是可取的，但在其他許多情況下，這可能會導致非常低效的查詢直到應用程式投入生產才被髮現。

在 EF Core 3.0 中，我們計劃深入更改 LINQ 實現工作原理和測試方式，旨在提高它的可靠性（例如，避免破壞修補程式版本中的查詢）；讓它能夠將更多運算式正確轉換為 SQL；在更多情況下生成高效查詢；以及防止直到投入生產才被檢測到的非常低效查詢出現。

我們一直在致力於開發適用於 EF Core 的 Cosmos DB 提供程式，以便開發人員能夠熟悉 EF 程式設計模型，從而輕鬆地將 Azure Cosmos DB 定標的為應用程式資料庫。標的是利用 Cosmos DB 的一些優勢，如全域性分發、“始終開啟”可用性、彈性可伸縮性和低延遲，甚至包括 .NET 開發人員可以更輕鬆地訪問它。此提供程式將針對 Cosmos DB 中的 SQL API 啟用大部分 EF Core 功能，如自動更改跟蹤、LINQ 和值轉換。

我們計劃在 EF Core 3.0 中新增的其他功能包括，屬性包物體（將資料儲存在索引屬性（而不是常規屬性）中的物體）；能夠將資料庫檢視反向工程為查詢型別；以及與新 C# 8.0 功能整合，如 IAsyncEnumerable 支援和可以為 null 的取用型別。

我們理解，對於許多使用舊版 EF 的現有應用程式來說，移植到 EF Core 的工作量巨大。正因為此，我們還移植了 EF 6，以便能夠使用 .NET Core。

.NET Standard 2.1

如果遵循 .NET Standard，可以建立適用於所有 .NET 實現的庫，不僅僅侷限於 .NET Core，還包括 Xamarin 和 Unity。在 .NET Standard 1.x 中，我們只對跨各種實現已常用的 API 進行了建模。在 .NET Standard 2.0 中，我們專註於簡化將現有 .NET Framework 程式碼移植到 .NET Core 的過程，這樣不僅帶來了額外的 20,000 個 API，還帶來了相容性樣式（可便於從基於 .NET Standard 的庫取用 .NET Framework 庫，而無需重新編譯它們）。對於這兩版標準，幾乎沒有任何新元件，因為所有 API 都是現有 .NET API。

在 .NET Standard 2.1 中，這一情況已有所改變：我們添加了約 3,000 個幾乎全新的 API，它們作為 .NET Core 開放原始碼開發的一部分引入。透過將它們新增到標準，我們將它們引入所有 .NET Standard 實現。

這些新 API 包括：

• Span：在 .NET Core 2.1 中，我們添加了 Span，這是類似陣列的型別，允許以統一方式表示託管和非託管記憶體，並支援在不複製的情況下進行切片。Span 是 .NET Core 2.1 中與效能最為相關的改進的核心。因為它允許以更高效的方式管理緩衝，所以可以有助於減少分配和複製。若要詳細瞭解此型別，請務必閱讀 Stephen Toub 關於 Span 的精彩文章 (msdn.com/magazine/mt814808)。
• ValueTask 和 ValueTask：在 .NET Core 2.1 中，基礎內容中最重要的功能相關改進，可支援高效能方案 (bit.ly/2HfIXob)，還能讓 async/await 更高效。 ValueTask 已有，可便於在操作同步完成時傳回結果，而無需分配新 Task。在 .NET Core 2.1 中，我們進一步改進了此功能，同時提高了它的可用性，讓它有對應的非泛型 ValueTask，以便在必須以非同步方式完成操作的情況下減少分配，這是 Socket 和 NetworkStream 等型別現在利用的功能。
• 常規實用 API：由於 .NET Core 是開放原始碼的，因此我們跨基類庫添加了許多小功能，如用於合併雜湊程式碼的 System.HashCode，或 System.String 上的新多載。.NET Core 中約有 800 名新成員，幾乎所有這些成員都已新增到 .NET Standard 2.1 中。

如需瞭解更多詳情，請檢視 .NET Standard 2.1 公告 (bit.ly/2RCW2fX)。

C# 8.0

C# 8.0 是下一版 C#，它在幾個主要方面改進了語言。可以為 null 的取用型別有助於防止 null 取用異常，並改進了 null 安全編碼做法。可以選擇啟用下列功能：在將 null 分配到型別字串（舉個例子）的變數或引數時看到警告。若要可以為 null，必須使用“string?”可以為 null 的取用型別。

非同步流對非同步資料流執行的操作，就是 async/await 對單個非同步結果執行的操作。新框架型別 IAsyncEnumerable 是 IEnumerable 的非同步版本，同樣也能執行 foreach 和 yield return：

public static async IAsyncEnumerable FilterAsync(
  this IAsyncEnumerable source,
  Func> predicate)
{
  await foreach (T element in source)
  {
    if (await predicate(element)) yield return element;
  }
}

除了其他功能外，藉助預設介面成員實現，介面可以新增新成員，而無需中斷現有實現者。Switch 運算式可確保樣式匹配更為簡潔，不僅可以遞迴樣式，還能將樣式深入挖掘到測試值。如需瞭解 C# 8.0 的更多詳情，請訪問 aka.ms/csharp8。

.NET Framework 和 .NET Core 將如何發展？

.NET Framework 是在超過 10 億臺計算機上安裝的 .NET 實現，因此需要盡可能保持相容性。因此，它的更新速度慢於 .NET Core。甚至安全修複和 bug 修複都可能會導致應用程式中斷，因為應用程式依賴舊行為。我們將確保 .NET Framework 始終支援最新的網路協議、安全標準和 Windows 功能。

.NET Core 是開放原始碼、跨平臺且快速更新的 .NET 版本。鑒於這種並行本質，可以對它應用我們無法冒險對 .NET Framework 應用的更改。也就是說，隨著時間推移，.NET Core 會增添新 API 和語言功能，而 .NET Framework 則不會。

如果現有 .NET Framework 應用程式，且無需利用任何 .NET Core 功能，就不應該有遷移到 .NET Core 的壓力。.NET Framework 和 .NET Core 都將完全受支援；.NET Framework 始終是 Windows 的一部分。甚至在 Microsoft 內部，我們都有很多基於 .NET Framework 的大型產品線，並將一直基於 .NET Framework。但展望未來，.NET Core 和 .NET Framework 包含的功能將會有所不同。

總結

.NET Core 3.0 預計將於 2019 年下半年釋出。它將提供開放原始碼版本的 WinForms 和 WPF，以用於 Windows 桌面開發。物體框架 6 也將包含在內。此外，ASP.NET Core、Entity Framework Core、.NET Standard 和 C# 都將進行重要更新。對於新 .NET 應用程式，應認真考慮使用此版本的 .NET Core。有關詳細資訊，請訪問 aka.ms/netcore3preview1。

我們對 .NET 的未來滿懷期待，並將向 .NET Core 新增更多工作負載。建議大家試用 .NET Core 3.0 預覽版，並向我們傳送反饋。

---

原文作者：Scott Hunter

原文地址：What’s Coming in .NET Core 3.0

原文地址：https://www.cnblogs.com/leolion/p/10585834.html