自從大約一年前[發佈 .NET Standard 2.0 ](https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/)以來,我們已經向 .NET Core 2.1 發佈了兩個更新,並即將發佈 .N... ...
[翻譯] .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!