.NET Standard 來日苦短去日長

精緻碼農發表於2020-10-13

作者：Richard
翻譯：精緻碼農-王亮
原文：http://dwz.win/Q4h

自從 .NET 5 宣貫以來，很多人都在問這對 .NET Standard 意味著什麼，它是否仍然重要。在這篇文章中，我將解釋 .NET 5 是如何改進程式碼共用並取代 .NET Standard 的，我還將介紹什麼情況下你仍然需要 .NET Standard。

概要

.NET 5 將是一個具有統一功能和 API 的單一產品，可用於 Windows 桌面應用程式、跨平臺移動應用程式、控制檯應用程式、雲服務和網站。

為了更好地說明這一點，我們更新了這篇[1]關於 TFM (Target Framework Names) 介紹的文章（譯文：.NET 5 中 Target Framework 詳解），現支援的 TFM 如下：

  • .net5.0，表示程式碼可在任意平臺執行，它合併並替換了 netcoreapp 和 netstandard 這兩個名稱。這個 TFM 通常只包括跨平臺的技術（除了一些為了滿足實用性而作出讓步的 API，就像我們在 .NET Standard 中所做的那樣）。
  • net5.0-windows（還有後面會增加的net6.0-android 和 net6.0-ios），這些 TFM 表示 .NET 5 特定於作業系統的風格，包含 net5.0 和特定於作業系統的功能。

我們不會再發布 .NET Standard 的新版本，但是 .NET 5 和所有未來的版本將繼續支援 .NET Standard 2.1 和更早的版本。你應該將 net5.0（和未來的版本）視為共享程式碼的基礎。

由於 net5.0 是所有這些新 TFM 的共用的基礎，這意味著執行時、庫和新的語言特性都會圍繞這個版本號進行協調。例如，為了使用 C# 9，你需要使用 net5.0 或 net5.0-windows。

如何選擇 Target

.NET 5 和所有未來的版本將繼續支援 .NET Standard 2.1 和更早的版本，從 .NET Standard 重新 Target 到 .NET 5 的唯一原因是為了獲得更多執行時特性、語言特性或 API 支援。所以，你可以把 .NET 5 想象成 .NET Standard 的 vNext。

那新程式碼呢？該從 .NET Standard 2.0 開始還是直接從 .NET 5 開始？這得視情況而定。

  • 應用程式元件，如果你要將你的應用程式以類庫的形式分解成多個元件，我建議將 netX.Y 作為 TFM，netX.Y 中的 X.Y 是應用程式（或多個應用程式）的 .NET 最低版本號。為了簡單起見，你可能希望所有組成你的應用程式的 Project 都使用相同的 .NET 版本，因為這樣可以保證各處的程式碼都可以使用相同的 BCL 特性。
  • 可重用庫，如果你正在構建計劃在 NuGet 上釋出的可重用庫，你將需要考慮適用範圍和可用新特性之間的權衡。.NET Standard 2.0 是 .NET Framework 支援的最高 .NET Standard 版本，所以它可以滿足你的大部分使用場景。我們通常建議不要將 Target 鎖定在 .NET Standard 1.x 上，因為不值得再為此增添不必要的麻煩。如果你不需要支援 .NET Framwork，那麼你可以選擇 .NET Standard 2.1 或者 .NET 5，大多數程式碼可能可以跳過 .NET Standard 2.1 直接轉到 .NET 5。

那麼，你應該怎麼做呢？我的建議是，已被廣泛使用的庫可能需要同時提供 .NET Standard 2.0 和 .NET 5 支援。支援 .NET Standard 2.0 將使你的庫適用性更廣，而支援 .NET 5 則確保你可以為已經在 .NET 5 上的使用者使用最新的平臺特性。

幾年後，可重用庫的選擇將只涉及 netX.Y 版本，這基本上是構建 .NET 庫的一慣做法——你通常要支援一段時間較老的版本，以確保沒有升級最新 .NET 版本的使用者依然可以使用你的庫。

總結一下：

  • 在 .NET Framework 和所有其他平臺之間共享程式碼，使用 netstandard2.0。
  • 在 Mono、Xamarin 和 .NET Core 3.x 之間共享程式碼，使用 netstandard2.1。
  • 往後的共享程式碼，使用 net5.0。

.NET 5 如何解決 .NET Standard 存在的問題

.NET Standard 使得建立適用於所有 .NET 平臺的庫變得更加容易，但是 .NET Standard 仍然存在三個問題：

  1. 它的版本更新很慢[2]，這意味著你不能輕鬆地使用最新的特性。
  2. 它需要一個解碼環[3]來將版本對映到 .NET 實現。
  3. 它公開了特定於平臺的特性[4]，這意味著你不能靜態地驗證程式碼是否真正可移植。

讓我們看看 .NET 5 將如何解決這三個問題。

問題 1：.NET Standard 版本更新慢

在設計 .NET Standard[5] 時，.NET 平臺還沒有在實現層次上融合，這使得編寫需要在不同環境下工作的程式碼變得困難，因為不同的工作程式碼使用的是不同的 .NET 實現。

.NET Standard 的目標是統一基礎類庫(BCL)的特性集，這樣你就可以編寫一個可以在任何地方執行的單一庫。這為我們提供了很好的服務：前 1000 個軟體包中有超過 77% 支援 .NET Standard。如果我們看看 NuGet.org 上所有在過去 6 個月裡更新過的軟體包，採用率是 58%。

但是隻標準化 API 就會產生額外的付出，它要求我們在新增新 API 時進行協調——這一直在發生。.NET 開源社群（包括.NET 團隊）通過提供新的語言特性、可用性改進、新的交叉(cross-cutting)功能（如 Span<T>）或支援新的資料格式或網路協議，不斷對 BCL 進行創新。

而我們雖然可以以 NuGet 包的形式提供新的型別，但不能以這種方式在現有型別上提供新的 API。所以，從一般意義上講，BCL 的創新需要釋出新版本的 .NET 標準。

在 .NET Standard 2.0 之前，這並不是一個真正的問題，因為我們只對現有的 API 進行標準化。但在 .NET Standard 2.1 中，我們對全新的 API 進行了標準化，這也是我們看到相當多摩擦的地方。

這種摩擦從何而來？

.NET 標準是一個 API 集，所有的.NET 實現都必須支援，所以它有一個編輯方面[6]的問題，所有的 API 必須由 .NET Standard 審查委員會[7]審查。該委員會由 .NET 平臺實現者以及 .NET 社群的代表組成。其目標是隻對我們能夠真正在所有當前和未來的 .NET 平臺中實現的 API 進行標準化。這些審查是必要的，因為 .NET 協議棧有不同的實現，有不同的限制。

我們預測到了這種型別的摩擦，這就是為什麼我們很早就說過，.NET 標準將只對至少一個 .NET 實現中已經推出的 API 進行標準化。這乍一看似乎很合理，但隨後你就會意識到，.NET Standard 不可能頻繁地更新。所以，如果一個功能錯過了某個特定的版本，你可能要等上幾年才能使用，甚至可能要等更久，直到這個版本的 .NET Standard 得到廣泛支援。

我們覺得對於某些特性來說，機會損失太大，所以我們做了一些不自然的行為，將還沒有推出的 API 標準化（比如 AsyncEnumerable<T>）。對所有的功能都這樣做實在是太昂貴了，這也是為什麼有不少功能還是錯過了 .NET Standard 2.1 這趟列車的原因（比如新的硬體特性）。

但如果有一個單一的程式碼庫呢？如果這個程式碼庫必須支援所有與 .NET 至今所實現功能有所不同的特性，比如同時支援及時編譯（JIT）和超前編譯（AOT）呢？

與其在事後才進行這些審查，不如從一開始就將所有這些方面作為功能設計的一部分。在這樣的世界裡，標準化的 API 集從構造上來說，就是通用的 API 集。當一個功能實現後，因為程式碼庫是共享的，所以大家就已經可以使用了。

問題 2：.NET Standard 需要解碼環

將 API 集與它的實現分離，不僅僅是減緩了 API 的可用性，這也意味著我們需要將 .NET Standard 版本對映到它們的實現上[3]。作為一個長期以來不得不向許多人解釋這個表格的人，我已經意識到這個看似簡單的想法是多麼複雜。我們已經盡力讓它變得更簡單，但最終，這種複雜性是與生俱來的，因為 API 集和實現是獨立釋出的。

我們統一了 .NET 平臺，在它們下面又增加了一個合成平臺，代表了通用的 API 集。從很現實的意義上來說，這幅漫畫是很到位的表達了這個痛點：

如果不能實現真正意義上的合併，我們就無法解決這個問題，這正是 .NET 5 所做的：它提供了一個統一的實現，各方都建立在相同的基礎上，從而得到相同的 API 和版本號。

問題 3：.NET Standard 公開了特定平臺 API

當我們設計 .NET Standard 時，為了避免過多地破壞庫的生態系統，我們不得不做出讓步[4]。也就是說，我們不得不包含一些 Windows 專用的 API（如檔案系統 ACL、登錄檔、WMI 等）。今後，我們將避免在 net5.0、net6.0 和未來的版本中加入特定平臺的 API。然而，我們不可能預測未來。例如，我們最近為 Blazor WebAssembly 增加了一個新的 .NET 執行環境，在這個環境中，一些原本跨平臺的 API（如執行緒或程式控制）無法在瀏覽器的沙箱中得到支援。

很多人抱怨說，這類 API 感覺就像“地雷”--程式碼編譯時沒有錯誤，因此看起來可以移植到任何平臺上，但當執行在一個沒有給定 API 實現的平臺上時，就會出現執行時錯誤。

從 .NET 5 開始，我們將提供隨 SDK 釋出的預設開啟的分析器和程式碼修復器。它包含平臺相容性分析器，可以檢測無意中使用了目標平臺並不支援的 API。這個功能取代了 Microsoft.DotNet.Analyzers.Compatibility NuGet 包。

讓我們先來看看 Windows 特有的 API。

處理 Windows 特定 API

當你建立一個 Target 為 net5.0 為目標的專案時，你可以引用 Microsoft.Win32.Registry 包。但當你開始使用它時：

private static string GetLoggingDirectory()
{
    using (RegistryKey key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam"))
    {
        if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
            return configuredPath;
    }

    string exePath = Process.GetCurrentProcess().MainModule.FileName;
    string folder = Path.GetDirectoryName(exePath);
    return Path.Combine(folder, "Logging");
}

你會得到以下警告：

CA1416: 'RegistryKey.OpenSubKey(string)' is supported on 'windows'
CA1416: 'Registry.CurrentUser' is supported on 'windows'
CA1416: 'RegistryKey.GetValue(string?)' is supported on 'windows'

你有三個選擇來處理這些警告。

  1. 呼叫保護：在呼叫 API 之前，你可以使用 OperatingSystem.IsWindows() 來檢查當前執行環境是否是 Windows 系統。

  2. 將呼叫標記為 Windows 專用：在某些情況下，通過 [SupportedOSPlatform("windows")] 將呼叫成員標記為特定平臺也有一定的意義。

  3. 刪除程式碼：一般來說，這不是你想要的，因為這意味著當你的程式碼被 Windows 使用者使用時，你會失去保真度(fidelity)。但對於存在跨平臺替代方案的情況，你應該儘可能使用跨平臺方案，而不是平臺特定的 API。例如，你可以使用一個 XML 配置檔案來代替使用登錄檔。

  4. 抑制警告：當然，你可以通過 .editorconfig 或 #pragma warning disable 來抑制警告。然而，當使用特定平臺的 API 時，你應該更喜歡選項 (1) 和 (2)。

為了呼叫保護，可以使用 System.OperatingSystem 類上的新靜態方法，示例：

private static string GetLoggingDirectory()
{
    if (OperatingSystem.IsWindows())
    {
        using (RegistryKey key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam"))
        {
            if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
                return configuredPath;
        }
    }

    string exePath = Process.GetCurrentProcess().MainModule.FileName;
    string folder = Path.GetDirectoryName(exePath);
    return Path.Combine(folder, "Logging");
}

要將你的程式碼標記為 Windows 專用，請應用新的 SupportedOSPlatform 屬性：

[SupportedOSPlatform("windows")]
private static string GetLoggingDirectory()
{
    using (RegistryKey key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam"))
    {
        if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
            return configuredPath;
    }

    string exePath = Process.GetCurrentProcess().MainModule.FileName;
    string folder = Path.GetDirectoryName(exePath);
    return Path.Combine(folder, "Logging");
}

在這兩種情況下，使用登錄檔的警告都會消失。

關鍵的區別在於，在第二個例子中，分析器現在會對 GetLoggingDirectory() 的呼叫發出警告，因為它現在被認為是 Windows 特有的 API。換句話說，你把平臺檢查的要求轉給呼叫者放去做了。

[SupportedOSPlatform] 屬性可以應用於成員、型別和程式集級別。這個屬性也被 BCL 本身使用，例如，程式集 Microsoft.Win32.Registry 就應用了這個屬性，這也是分析器最先就知道登錄檔是 Windows 特定 API 方法的原因。

請注意，如果你的目標是 net5.0-windows，這個屬性會自動應用到你的程式集中。這意味著使用 net5.0-windows 的 Windows 專用 API 永遠不會產生任何警告，因為你的整個程式集被認為是 Windows 專用的。

處理 Blazor WebAssembly 不支援的 API

Blazor WebAssembly 專案在瀏覽器沙盒內執行，這限制了你可以使用的 API。例如，雖然執行緒和程式建立都是跨平臺的 API，但我們無法讓這些 API 在 Blazor WebAssembly 中工作，它們會丟擲 PlatformNotSupportedException。我們已經用 [UnsupportedOSPlatform("browser")] 標記了這些 API。

假設你將 GetLoggingDirectory() 方法複製並貼上到 Blazor WebAssembly 應用程式中：

private static string GetLoggingDirectory()
{
    //...

    string exePath = Process.GetCurrentProcess().MainModule.FileName;
    string folder = Path.GetDirectoryName(exePath);
    return Path.Combine(folder, "Logging");
}

你將得到以下警告：

CA1416 'Process.GetCurrentProcess()' is unsupported on 'browser'
CA1416 'Process.MainModule' is unsupported on 'browser'

你可以用與 Windows 特定 API 基本相同的做法來處理這些警告。

你可以對呼叫進行保護：

private static string GetLoggingDirectory()
{
    //...

    if (!OperatingSystem.IsBrowser())
    {
        string exePath = Process.GetCurrentProcess().MainModule.FileName;
        string folder = Path.GetDirectoryName(exePath);
        return Path.Combine(folder, "Logging");
    }
    else
    {
        return string.Empty;
    }
}

或者你可以將該成員標記為不被 Blazor WebAssembly 支援：

[UnsupportedOSPlatform("browser")]
private static string GetLoggingDirectory()
{
    //...

    string exePath = Process.GetCurrentProcess().MainModule.FileName;
    string folder = Path.GetDirectoryName(exePath);
    return Path.Combine(folder, "Logging");
}

由於瀏覽器沙盒的限制性相當大，所以並不是所有的類庫和 NuGet 包都能在 Blazor WebAssembly 中執行。此外，絕大多數的庫也不應該支援在 Blazor WebAssembly 中執行。

這就是為什麼針對 net5.0 的普通類庫不會看到不支援 Blazor WebAssembly API 的警告。你必須在專案檔案中新增 <SupportedPlatform> 項，明確表示你打算在 Blazor WebAssembly 中支援您的專案：

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net5.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <SupportedPlatform Include="browser" />
  </ItemGroup>

</Project>

如果你正在構建一個 Blazor WebAssembly 應用程式，你不必這樣做，因為 Microsoft.NET.Sdk.BlazorWebAssembly SDK 會自動做到這一點。

.NET 5 是 .NET Standard 和 .NET Core 的結合

.NET 5 及後續版本將是一個單一的程式碼庫，支援桌面應用、移動應用、雲服務、網站以及未來的任何 .NET 執行環境。

你可能會想“等等，這聽起來很不錯，但如果有人想建立一個全新的實現呢”。這也是可以的。但幾乎沒有人會從頭開始一個新的實現。最有可能的是，它將是當前程式碼庫（dotnet/runtime[8]）的一個分支。例如，Tizen（三星智慧家電平臺）使用的是 .NET Core，只做了細小的改動，並在上面使用了三星特有的應用模型。

Fork 保留了合併關係，這使得維護者可以不斷從 dotnet/runtime[8] 倉庫中拉取新的變化，在不受其變化影響的領域受益於 BCL 創新，這和 Linux 發行版的工作方式非常相似。

當然，在某些情況下，人們可能希望建立一個非常不同的“種類”的 .NET，比如一個沒有當前 BCL 的最小執行時。但這意味著它不能利用現有的 .NET 庫生態系統，它也不會實現 .NET Standard。我們一般對這個方向的追求不感興趣，但 .NET Standard 和 .NET Core 的結合並不妨礙這一點，也不會增加難度。

.NET 版本

作為一個庫作者，你可能想知道 .NET 5 什麼時候能得到廣泛支援。今後，我們將在每年的 11 月釋出 .NET 新版本，每隔一年釋出一次長期支援（LTS）版本。

.NET 5 將在 2020 年 11 月正式釋出，而 .NET 6 將在 2021 年 11 月作為 LTS 釋出。我們建立了這個固定的時間表，使你更容易規劃您的更新（如果你是應用程式開發人員），並預測對支援的 .NET 版本的需求（如果你是庫開發人員）。

得益於 .NET Core 的並行安裝（譯註：一臺機器可同時安裝多個 .NET Core 版本，且向下相容），它的新版本被採用速度相當快，其中 LTS 版本最受歡迎。事實上，.NET Core 3.1 是有史以來採用最快的 .NET 版本。

我們的期望是，每次釋出（大版本）時，我們都會把所有框架名稱連在一起釋出。例如，它可能看起來像這樣：

這意味著你心裡可以有個預期，無論我們在 BCL 中做了什麼創新，你都能在所有的應用模型中使用它，無論它們執行在哪個平臺上。這也意味著，只要你執行最新版本的庫，你總是可以在所有的應用模型消費最新的 net 框架帶來的庫。

這種模式消除了圍繞 .NET Standard 版本的複雜性，因為每次我們釋出時，你都可以假設所有的平臺都會立即和完全支援新版本，而我們通過使用字首命名慣例來鞏固這一承諾。

.NET 的新版本可能會新增對其他平臺的支援。例如，我們將通過 .NET 6 增加對 Android 和 iOS 的支援。相反，我們可能會停止支援那些不再相關的平臺。這一點可以通過在 .NET 6 中不存在的 net5.0-someoldos 目標框架來說明。我們目前沒有放棄一個平臺支援的計劃，那將是一個大問題，這不是預期的，若有我們會提前很久宣佈。這也是我們對 .NET Standard 的模式，例如，沒有新版本的 Windows Phone 實現了後面的 .NET Standard 版本。

為什麼沒有 WebAssembly 的 TFM

我們最初考慮為 WebAssembly 新增 TFM，如 net5.0-wasm。後來我們決定不這麼做，原因如下：

  • WebAssembly 更像是一個指令集（如 x86 或 x64），而不是像一個作業系統，而且我們一般不提供不同架構之間有分歧的 API。

  • WebAssembly 在瀏覽器沙箱中的執行模型是一個關鍵的差異化，但我們決定只將其建模為執行時檢查更有意義。類似於你對 Windows 和 Linux 的檢查方式，你可以使用 OperatingSystem 型別。由於與指令集無關，所以該方法被稱為 IsBrowser() 而不是 IsWebAssembly()。

  • WebAssembly 有執行時識別符號(RID)[9]，稱為 browser 和 browser-wasm。它們允許包的作者在瀏覽器中針對 WebAssembly 部署不同的二進位制檔案。這對於需要事先編譯成 WebAssembly 的原生程式碼特別有用。

如上所述，我們已經標記了在瀏覽器沙盒中不支援的 API，例如 System.Diagnostics.Process。如果你從瀏覽器應用內部使用這些 API，你會得到一個警告，告訴你這個 API 是不支援的。

總結

net5.0 是為能在任何平臺執行的程式碼而設計的，它結合並取代了 netcoreapp 和 netstandard 名稱。我們還有針對特定平臺的框架，比如 net5.0-windows（後面還有 net6.0-android，net6.0-ios）。

由於標準和它的實現之間沒有區別，你將能夠比使用 .NET Standard 更快地利用新功能。而且由於命名慣例，你將能夠很容易地知道誰可以使用一個給定的庫--而無需查閱 .NET Standard 版本表。

雖然 .NET Standard 2.1 將是 .NET Standard 的最後一個版本，但 .NET 5 和所有未來的版本將繼續支援.NET Standard 2.1 和更早的版本。你應該將 net5.0（以及未來的版本）視為未來共享程式碼的基礎。

祝，編碼愉快！

文中相關連結：

[1].https://github.com/dotnet/designs/blob/master/accepted/2020/net5/net5.md
[2].https://github.com/dotnet/standard/tree/master/docs/governance#process
[3].https://dotnet.microsoft.com/platform/dotnet-standard#versions
[4].https://github.com/dotnet/standard/blob/master/docs/faq.md#why-do-you-include-apis-that-dont-work-everywhere
[5].https://devblogs.microsoft.com/dotnet/introducing-net-standard/
[6].https://github.com/dotnet/standard/tree/master/docs/governance#process
[7].https://github.com/dotnet/standard/blob/master/docs/governance/board.md
[8].https://github.com/dotnet/runtime
[9].https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

相關文章