1. 程式人生 > >[翻譯] .NET Standard 2.1 公佈

[翻譯] .NET Standard 2.1 公佈

[翻譯] .NET Standard 2.1 公佈

原文: Announcing .NET Standard 2.1
校對: Cloud

自從大約一年前釋出 .NET Standard 2.0以來,我們已經向 .NET Core 2.1 釋出了兩個更新,並即將釋出 .NET Core 2.2 。 現在是時候更新 Standard 了,包括一些新的概念以及一些小改進,使您在不同的 .NET 實現裡編碼生活更輕鬆。

繼續閱讀以瞭解有關此最新版本中新功能的更多資訊,以及有關平臺支援、治理和編碼的資訊。

NET Standard 2.1 有哪些新功能?

總的來說,計劃在 .NET Standard 2.1 中新增大約 3000 個 API 。其中很大一部分是全新的,
而其他部分則是現有的API,新增到 Standard 中,以便進一步使 .NET 實現一致。

以下是其中的亮點:

  • Span 。 在 .NET Core 2.1 中,我們添加了 Span ,這是一種類似於陣列的型別,允許以統一的方式表示託管和非託管記憶體,並支援切片而無需複製。它是 .NET Core 2.1 中與效能相關的大多數改進的核心。由於它允許以更有效的方式管理緩衝區,因此可以幫助減少記憶體分配和複製。我們認為Span 應該是一種非常基礎的型別,因為它需要執行時和編譯器支援才能充分利用。如果您想了解有關此型別的更多資訊,請務必閱讀 Stephen Toub 關於 Span 的優秀文章
  • 使用 span 的基礎 API。雖然 Span 已經作為 .NET Standard 相容的 NuGet 包(System.Memory)提供,但新增此包不能擴充套件 .NET Standard 型別的成員去使用 span。例如,.NET Core 2.1添加了許多允許使用 span 的API,如 Stream.Read(Span )。將 span 帶入 .Net Standard 的話,新增這些 API 是很重要的一部分。
  • 反射 emit。為了提高生產力,.NET生態系統一直大量使用動態功能,如反射和反射 emit。 Emit 通常用作優化效能的工具,以及為代理介面動態生成型別的方法。因此,許多人要求反射 emit 包含在 .NET standard 中。之前,我們試圖通過 NuGet 包提供這個,但我們發現無法使用包來模擬這樣的核心技術。在 .NET Standard 2.1 中,您可以使用輕量級程式碼生成(LCG)以及反射 emit。當然,您可能執行在不支援通過解釋執行 IL 或使用 JIT 編譯它的執行時,因此我們還公開了兩個新的功能 API,允許您檢查生成程式碼的能力(RuntimeFeature.IsDynamicCodeSupported)以及是否解釋或編譯生成的程式碼(RuntimeFeature.IsDynamicCodeCompiled)。這將使編寫可移植的庫變得容易得多。
  • SIMD。.NET Framework 和 .NET Core 現在已經支援 SIMD 一段時間了。我們利用它們來加速BCL 中的基本操作,例如字串的比較。我們收到了很多在 .NET Standard 中公開這些 API 的請求,因為這些功能需要執行時支援,因此無法作為 NuGet 包來提供。
  • ValueTask ValueTask .NET Core 2.1 最大的功能是改進了我們支援高效能場景的基礎知識,其中還包括提高 async/await 效率。 ValueTask 已經存在,如果操作同步完成, 則允許返回結果,而無需分配新的 Task 。在 .NET Core 2.1 中,我們進一步改進了這一點,這使得有一個相應的非泛型 ValueTask 變得很有用,它允許減少分配記憶體,即使是在必須非同步完成操作的情況下也是如此,現在使用類似 Socket 和 NetworkStream 的功能。在 .NET Standard 2.1 中公開這些 API 會使庫作者能夠作為消費者和生產者從其中受益。
  • DbProviderFactories。在 .NET Standard 2.0 中,我們在 ADO.NET 中添加了幾乎所有基元型別,以允許 ORM 和資料庫實現者進行通訊。不幸的是,DbProviderFactories 沒有新增在其中,所以我們現在新增它。簡而言之,DbProviderFactories 允許庫和應用程式在編譯時使用特定的ADO.NET 提供程式而不需要知道任何特定型別,方法是在基於名稱的已註冊 DbProviderFactory 例項中進行選擇,例如,可以從配置設定中讀取。
  • General Goodness. 自從 .NET Core 開源後,我們在基礎類庫中添加了許多小功能,例如System.HashCode 用於組合 hash code 或 System.String 上的新過載。.NET Core 中大約有800個新成員,幾乎所有成員都加入了 .NET Standard 2.1。

有關更多詳細資訊,您可能需要檢視 .NET Standard 2.1 和 2.0 之間的完整 API 差異。您還可以使用 apisof.net 快速檢查 .NET Standard 2.1 中是否包含某些 API。

.NET 平臺支援

如果您錯過了我們的 .NET Core 3.0 和 .NET Framework 4.8 更新,其中已經描述了我們對 .NET Framework 和 .NET Core 的支援,如下所示:

  • .NET Framework 是 .NET 的實現,它安裝在超過 10 億臺計算機上,因此需要保持儘可能的相容。因此,它的更新速度要比 .NET Core 慢。即使安全性和小錯誤修復也會導致應用程式中斷,因為應用程式依賴於先前的行為。我們將確保 .NET Framework 始終支援最新的網路協議、安全標準和Windows 功能。

  • .NET Core 是 .NET 的開源、跨平臺和快速移動版本。由於它的 side-by-side 性質,它可以進行一些無法在 .NET Framework 上冒險進行的修改。這意味著 .NET Core 將隨著時間的推移獲得 .NET Framework 無法獲得的新 API 和語言功能。在 Build 大會中,我們展示了 .NET Core 上檔案 API 如何比之前更快。如果我們將這些相同的更改放入 .NET Framework ,我們可能會破壞現有的應用程式,我們不希望這樣做。

鑑於 .NET Standard 2.1 中的許多 API 新增需要修改執行時才能有意義,.NET Framework 4.8將保留在 .NET Standard 2.0 上,而不是實現 .NET Standard 2.1 。.NET Core 3.0 以及即將推出的 Xamarin,Mono 和 Unity 版本將更新以實現 .NET Standard 2.1。

需要支援 .NET Framework 客戶的庫作者應該繼續使用 .NET Standard 2.0。實際上,大多數庫都可以保留在 .NET Standard 2.0 上,因為新新增的 API 主要用於高階場景。但是,這並不意味著庫作者無法利用這些 API,即使他們必須支援 .NET Framework。在這些情況下,他們可以使用多目標來編譯 .NET Standard 2.0 和 .NET Standard 2.1。這允許編寫可以暴漏更多特性的程式碼,或者在支援 .NET Standard 2.1 的執行時上提供更高效的實現,同時不放棄 .NET Standard 2.0 提供的更大的支援範圍。

有關多目標的更多推薦,請檢視跨平臺目標的最新文件。

Governance model 治理模式

.NET Standard 1.x 和 2.0 版本專注於揭露現有概念。大部分工作都在 .NET Core 方面,因為該平臺從更小的 API 集開始。在前進的道路上,我們通常必須標準化全新技術,這意味著我們需要考慮對所有 .NET 實現的影響,而不僅僅是 .NET Core ,包括在其他社群(如 Mono 或 Unity )中管理的那些。我們的治理模式已經更新,來考慮所有因素:

.NET Standard 稽核委員會。為確保我們不會最終新增無法實現的大量 API,稽核委員會將簽署有關 .NET Standard 的 API 新增內容。該委員會由 .NET 平臺、Xamarin、Mono、Unity 和 .NET Foundation 的代表組成,將由 Miguel de Icaza 擔任主席。我們將繼續努力根據共識做出決策,並將利用 Miguel 的廣泛專業知識和經驗來構建 .NET 的實現,並在需要時得到多方的支援。

正式批准流程。.NET Standard 1.x 和 2.0 版本在很大程度上是通過計算現有 .NET 實現的 API 共同來實現的,這意味著 API 集實際上是計算結果。展望未來,我們正在實施一種社群策略:

  • 任何人都可以向 .NET Standard 提交 API 新增建議
  • 預設認為已有實現中的成員存在 Standard 中。為了防止意外的分裂,我們將預設認為任何 .NET 實現已經新增的所有成員已經存在在 Standard 中。這裡的基本原則是成員級別的分歧是不可取的,除非API 出現問題,否則很可能是一個很好的補充。
  • 驗收要求:
    • 稽核委員會成員的響應。該人將被分配該問題,並且引導這個問題,直至其被接受或被拒絕。如果沒有董事會成員願意響應該提案,將被視為被拒絕。
    • 至少在一個 .NET 實現中穩定實現。這個實現必須授權在與 MIT 相容的開源許可下。這將允許其他 .NET 實現啟動他們自己的實現或只是按原樣使用該功能。
  • .NET Standard 更新是由計劃的,通常會遵循一組主題。我們避免釋出大量不屬於一組常見方案的微小功能。相反,我們嘗試定義一組目標,以描述特定 .NET Standard 版本提供的功能區域型別。這簡化了某些庫應該依賴於 .NET Standard 的問題。它還使 .NET 實現更容易決定是否值得實現更高版本的 .NET Standard。
  • 版本號需要經過討論,通常它是很重要的。雖然我們不打算進行重大更改,但如果新版本添加了大量API(例如,當我們將 .NET Standard 2.0 中的 API 數量增加一倍時),或者整個開發體驗有了相當大的改變,我們將修改 major 版本(就像我們在 .NET Standard 2.0 中新增的.NET Framework 庫一樣,增加了相容性模式)。

有關更多資訊,請檢視 .NET Standard 治理模式.NET 標準稽核委員會
For more information, take a look at the .NET Standard governance model and the .NET Standard review board.

總結

.NET Standard 2.1 的定義正在進行中。您可以在 GitHub 上觀看我們的進度並提出請求。

如果要快速檢查特定 API 是否在 .NET Standard(或任何其他.NET平臺)中,可以使用 apisof.net 。您還可以使用 .NET 可移植性分析器檢查現有專案是否可以移植到.NET Standard 2.1。

Happy coding!