自從.NET 5 發(fā)布以來，許多人都在問它對.NET Standard 意味著什么，想知道它是不是還能吸引主流開發(fā)人員的興趣。

在本文中，我將介紹.NET 5 是如何改善代碼共享并替代.NET Standard 的。同時，我還將介紹一些仍然需要.NET Standard 的情況。

TL;DR

.NET 5 將是一個具有一組統(tǒng)一特性和 API 的單一產品，可用于 windows 桌面應用、跨平臺移動應用、控制臺應用、云服務和網站。

為更好地反映這一點，我們更新了目標框架名稱（TFM）：

• net5.0。這適用于運行在所有平臺上的代碼。它合并并替換了netcoreApp和netstandard名稱。這個 TFM 總體上只包括跨平臺工作的技術（除了一些特例，就像我們在.NET Standard 中所做的那樣）。
• net5.0-windows（以及之后的net6.0-Android和net6.0-IOS）。這些 TFM 代表特定于 OS 的.NET 5 風味，其中包括net5.0加上特定于 OS 的特性。

我們不會再發(fā)布.NET Standard 的新版本了，但是.NET 5 和所有將來的版本都會繼續(xù)支持.NET Standard 2.1 和更早版本。你應該將net5.0（及以后的版本）視為未來共享代碼的基礎。

由于net5.0是所有這些新 TFM 的共享基礎，因此這意味著運行時、庫和新的語言特性將圍繞這個版本號來運作。例如，為了使用 C# 9，你需要使用net5.0或net5.0-windows。

你的目標應該是什么

.NET 5 和將來所有的版本都會一直支持.NET Standard 2.1 和更早版本。從.NET Standard 目標切換到.NET 5 的唯一理由是可以訪問更多的運行時特性、語言特性或 API。因此，你可以將.NET 5 視為.NET Standard 的 vNext。

新代碼呢？你還是應該從.NET Standard 2.0 開始還是應該直接進入.NET 5？這要看具體情況。

• 應用組件。如果你使用庫將應用程序分解為多個組件，我的建議是使用netX.Y，其中X.Y是應用程序（或多個應用程序）目標的最低.NET。為簡單起見，你可能希望組成應用程序的所有項目都位于同一版本的.NET 上，因為這樣以來，你就可以在所有地方都獲得相同的 BCL 特性。
• 可重用的庫。如果你要構建計劃在 NuGet 上發(fā)布的可重用庫，則需要考慮覆蓋率和可用特性集之間的權衡。.NET Standard 2.0 是.NET Framework 支持的.NET Standard 的最高版本，因此它將為你提供最大的覆蓋范圍，同時還為你提供了相當大的特性集。我們通常建議你不要以.NET Standard 1.x 為目標，因為麻煩事太多了。如果你不需要支持.NET Framework，則可以使用.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 構建庫的標準途徑——通常來說，你會希望支持某些較舊的版本，以確保獲得最大的采用率。

總結一下：

• 使用netstandard 2.0在.NET Framework 和其他所有平臺之間共享代碼。
• 使用netstandard 2.1在 Mono、Xamarin 和.NET Core 3.x 之間共享代碼。
• 使用net5.0為將來的項目進行代碼共享。

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

.NET Standard 讓開發(fā)人員可輕松創(chuàng)建適用于所有.NET 平臺的庫。但是，.NET Standard 仍然存在三個問題：

1. 它的版本更替很慢，這意味著你無法輕松使用最新特性。
2. 它需要一個解碼器環(huán)才能將版本映射到.NET 實現。
3. 它公開了特定于平臺的特性，這意味著你無法靜態(tài)驗證代碼是否真正可移植。

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

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

.NET Standard 是.NET 平臺尚未在實現級別融合的時候設計的。這使開發(fā)人員很難編寫需要在不同環(huán)境中運行的代碼，因為不同的負載使用了不同的.NET 實現。

.NET Standard 的目標是統(tǒng)一基類庫（BCL）的特性集，以便你可以編寫可在任何地方運行的庫。這對我們很有幫助：.NET Standard 在前 1000 個軟件包中得到了 77％以上的支持。而且，如果我們查看 NuGet.org 上最近 6 個月中更新的所有軟件包，則采用率是 58％。

支持.NET Standard 的包：

但是單獨標準化 API 集會有代價。每當我們添加新的 API 時都需要協調。.NET 開源社區(qū)（包括.NET 團隊）通過提供新的語言特性、可用性改進、新的跨領域特性（例如Span<T>）或支持新的數據格式或網絡協議，以在 BCL 中不斷創(chuàng)新前進。

盡管我們可以將新類型作為 NuGet 包來提供，但我們不能以這種方式在現有類型上提供新的 API。因此從一般意義上講，BCL 中的創(chuàng)新需要交付新版本的.NET Standard。

在.NET Standard 2.0 之前，這并不是什么大問題，因為我們僅對現有的 API 進行了標準化。但是在.NET Standard 2.1 中，我們對全新的 API 進行了標準化，因此我們遇到了很多麻煩。

這種摩擦從何而來？

.NET Standard 是所有.NET 實現都必須支持的 API 集，因此它有一個編輯準則，即所有 API 必須由.NET Standard 審查委員會審查。該委員會由.NET 平臺實現者和.NET 社區(qū)的代表組成，目標是僅標準化我們可以在所有當前和將來的.NET 平臺中真正實現的 API。這些檢查是必要的，因為.NET 堆棧的實現方式不同，約束條件也不同。

我們預測到了這種摩擦，這就是為什么我們之前提到.NET Standard 只會標準化至少在一個.NET 實現中提供 API 的原因。一開始這似乎挺合理，但隨后，你就意識到.NET Standard 不能頻繁發(fā)布新版本。因此，如果某個特性錯過了某個特定版本，則可能需要等上幾年才能發(fā)布，甚至可能需要更長時間才能等到這個版本的.NET Standard 得到廣泛支持。

對某些特性來說，我們感到機會成本太高了，因此我們采取了非常規(guī)的行動來標準化尚未交付的 API（例如IAsyncEnumerable<T>）。但是，對所有特性都這么做，實在是太昂貴了，這就是為什么許多特性仍然錯過了.NET Standard 2.1 的原因（例如新的硬件內部函數）。

但是，如果只有一個代碼庫呢？如果這個代碼庫需要支持現在讓.NET 實現分裂的所有選項，例如同時支持即時（JIT）編譯和提前（AOT）編譯，又會怎么樣？

從一開始，我們就將所有這些選項都納入了特性設計，而不是事后才考慮。在這種情況下，標準化的 API 集在構造上就是通用的 API 集。一個特性被實現后，由于代碼庫是共享的，因此這個特性立刻就能被所有人使用。

問題 2：.NET Standard 需要解碼環(huán)

將 API 集與對應的實現分離，不僅僅是減緩了 API 的可用性，這也意味著我們需要將.NET Standard 版本映射到它們的實現上。隨著時間的推移，我需要向越來越多的人解釋這種關系，于是發(fā)現這種看似簡單的想法其實非常復雜。我們盡了最大的努力來簡化它，但畢竟這是固有的復雜性，因為 API 集和實現是分開獨立提供的。

我們統(tǒng)一了 .NET 平臺，在它們下面又增加了一個合成平臺，代表了通用的 API 集。這幅受 XKCD 啟發(fā)的漫畫就畫得很明白：

.NET 5 要做的就是真正在框架中合并一些部分，從而解決這個問題：.NET 5 提供了一個統(tǒng)一的實現，所有部分都在相同的基礎上構建，并因此獲得相同的 API 形狀和版本號。

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

在設計.NET Standard 時，我們必須做出務實的妥協，以免對庫生態(tài)系統(tǒng)造成過大的破壞。換句話說，我們必須包括一些只適用于Windows 的API（例如文件系統(tǒng)ACL、注冊表、WMI 等）。展望未來，我們將避免在 net5.0、net6.0和以后的版本中添加特定于平臺的 API。但我們無法預測未來，例如，借助 Blazor WebAssembly，我們最近添加了一個新環(huán)境，可以在其中運行.NET，可瀏覽器的沙箱中不支持某些跨平臺 API（例如線程或進程控制）。

很多人抱怨說，這類 API 就像“地雷”一樣——代碼編譯沒有錯誤，因此似乎可以移植到任何平臺，但是在沒有針對給定 API 實現的平臺上運行時就會出現運行時錯誤。

從.NET 5 開始，我們將默認隨附帶有 SDK 的分析器和代碼修復程序，其中包括平臺兼容性分析器，該分析器可檢測到你準備運行的平臺上不支持哪些API，并報告相應的意外使用情況。此特性替代了 Microsoft.DotNet.Analyzers.Compatibility NuGet 包。

首先，讓我們看一下 Windows 專屬的 API。

處理特定于 Windows 的 API

創(chuàng)建以 net5.0 為目標的項目時，可以引用 Microsoft.Win32.Registry 包。但當你開始使用它時，會收到以下警告：

private static string GetLoggingDirectory()
{    
     using (RegistryKey key = Registry.CurrentUser.OpenSubKey(@"SoftwareFabrikam"))
     { 
          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. 守護調用。你可以使用OperatingSystem.IsWindows()，在調用 API 之前檢查你是否在 Windows 上運行。
2. 將調用標記為 Windows 專屬。在某些情況下，可以通過[SupportedOSPlatform("windows")]將調用成員標記為平臺專屬。
3. 刪除代碼。通常這不是你想要的，因為這意味著 Windows 用戶使用你的代碼時會損失一些內容，但是對于存在跨平臺替代方案的情況，你最好放棄那些平臺專屬的代碼。例如，可以使用 XML 配置文件來替代注冊表。
4. 禁止警告。你當然可以通過.editorconfig或#pragmawarningdisable來作弊，簡單地禁用警告。但是，在使用特定于平臺的 API 時，你應該選擇選項（1）和（2）。

為了守護調用，請在 System.OperatingSystem 類上使用新的靜態(tài)方法，例如：

private static string GetLoggingDirectory()
{   
    if (OperatingSystem.IsWindows())  
    {  
        using (RegistryKey key = Registry.CurrentUser.OpenSubKey(@"SoftwareFabrikam"))  
        {
             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(@"SoftwareFabrikam"))
    {  
        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");
}

在這兩種情況下，使用注冊表的警告都會消失。

關鍵區(qū)別在于，在第二個示例中，分析器現在將針對GetLoggingDirectory()的調用站點發(fā)出警告，因為它現在被視為 Windows 特定的 API。換句話說，你將進行平臺檢查的要求轉發(fā)給了調用者。

[SupportedOSPlatform]屬性可以應用于成員、類型或程序集級別。BCL 本身也使用此屬性。例如，程序集Microsoft.Win32.Registry應用了此屬性，所以分析器能先知道注冊表是 Windows 特定的 API。

請注意，如果你以net5.0-windows為目標，此屬性將自動應用于你的程序集。這意味著從net5.0-windows使用 Windows 專屬的 API 永遠不會產生任何警告，因為你的整個程序集都被視為 Windows 專屬的。

處理 Blazor WebAssembly 中不支持的 API

Blazor WebAssembly 項目在瀏覽器沙箱中運行，這限制了你可以使用的 API。例如，盡管線程和進程創(chuàng)建都是跨平臺的 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的常規(guī)類庫不會看到 Blazor WebAssembly 不支持的 API 警告。你必須通過在項目文件中添加項，來顯式聲明你打算在 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 會自動執(zhí)行此操作。

.NET 5 作為.NET Standard 和.NET Core 的組合

.NET 5 及其后續(xù)版本將是一個單一代碼庫，它支持桌面應用、移動應用、云服務、網站以及未來.NET 將會運行的任何環(huán)境。

你可能會認為“等等，這聽起來不錯，但是如果有人想創(chuàng)建一個全新的實現該怎么辦”。這也是可以的。但實際上沒有人會從頭開始。這樣的實現很可能是當前代碼庫（ dotnet/runtime ）的分支。例如，Tizen（三星用于智能設備的平臺）使用了一個經過少量改動的.NET Core，并且在頂層使用了一個三星定制的應用模型。

分叉保留了合并關系，維護人員可以從不受其更改影響的 BCL 創(chuàng)新中受益，從而繼續(xù)從 dotnet/runtime 倉庫中拉取新更改。這與 linux 發(fā)行版的機制非常相似。

當然，在某些情況下，你可能想創(chuàng)建一種非常不同的.NET“類別”，例如在沒有當前 BCL 的情況下最小化運行時。但這意味著它無論如何都無法利用現有的.NET 庫生態(tài)系統(tǒng)，也就是說，它也不會實現.NET Standard。我們對這個方向總體來說并不感興趣，但是.NET Standard 和.NET Core 的融合并不能阻止這一點，也不會為其增加障礙。

.NET 版本控制

作為庫作者，你可能想知道.NET 5 何時才能得到廣泛支持。展望未來，我們將在每年 11 月發(fā)布.NET，每隔一年將發(fā)布一個長期支持（LTS）版本。

.NET 5 將于 2020 年 11 月發(fā)布，.NET 6 將于 2021 年 11 月發(fā)布，是 LTS 版。我們定下了這個固定的時間表，以便大家更輕松地安排更新計劃（如果你是應用開發(fā)人員），和預測對.NET 版本的支持需求（如果你是庫開發(fā)人員）。

由于.NET Core 能夠并行安裝，因此新版本的采用速度相當快，其中 LTS 版本最為流行。實際上，.NET Core3.1 是有史以來普及最快的.NET 版本。

.NET 5 時間表

可以預計每次交付時，我們都會一并更新所有框架名稱。例如，計劃可能是這個樣子：

換句話說，你基本上可以指望：無論我們在 BCL 中所做的創(chuàng)新如何，無論它們運行在哪個平臺上，你都將能在所有應用模型中使用它。這也意味著，只要運行最新版本的.NET，就始終可以在所有應用模型中使用為最新的net框架提供的庫。

這種模式消除了.NET Standard 版本控制的復雜性，因為每次發(fā)布新版時，你都可以假定所有平臺都將立即且完全支持新版本。我們還使用前綴命名約定來鞏固這一承諾。

.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），而非操作系統(tǒng)。而且，我們通常不會在不同的架構之間提供不同的 API。
• 瀏覽器沙箱中的 WebAssembly 執(zhí)行模型是一個重大創(chuàng)新，但我們認為僅將其建模為一個運行時檢查更有意義。與檢查 Windows 和 Linux 的方式類似，你可以使用 OperatingSystem 類型。由于這與指令集無關，因此該方法稱為IsBrowser()而不是IsWebAssembly()。
• WebAssembly 有運行時標識符（ RID ），稱為browser和browser-wasm。它們允許包作者以瀏覽器中的 WebAssembly 為目標時部署不同的二進制文件。這對于需要事先編譯為 Web 程序集的原生代碼特別有用。

如上所述，我們標記了瀏覽器沙箱中不支持的 API，例如System.Diagnostics.Process。如果你是從瀏覽器應用中使用這些 API，則會收到警告，告知你不支持該 API。

總結

net5.0適用于在各種平臺上運行的代碼。它合并并替換了netcoreapp和netstandard名稱。我們還有特定于平臺的框架，例如net5.0-windows（以及后來的net6.0-android和net6.0-ios）。

由于標準與其實現之間沒有區(qū)別，因此你可以比.NET Standard 更快地利用新特性。而且，由于采用了命名約定，你就能輕松判斷誰可以使用給定的庫，而無需查閱.NET Standard 版本表。

.NET Standard 2.1 將是.NET Standard 的最后版本，而.NET 5 和所有將來的版本將繼續(xù)支持.NET Standard 2.1 和更早版本。你應該將 net5.0（及以后的版本）視為共享代碼的基礎。

原文鏈接：

https://devblogs.microsoft.com/dotnet/the-future-of-net-standard/