.NET Standard
.NET Standard 是多個 .NET 實作中提供的 .NET API 的正式規格。 .NET Standard 背後的動機是在 .NET 生態系統中建立更高的一致性。 .NET 5 和更新版本採用不同的方法來建立統一性，以消除在大部分案例中對於 .NET Standard 的需求。 不過，如果您想要在 .NET Framework 與任何其他 .NET 實作 (例如 .NET Core) 之間共用程式碼，您的程式庫應該以 .NET Standard 2.0 為目標。 不會發行 .NET Standard 的新版本，但 .NET 5 和所有更新版本會繼續支援 .NET Standard 2.1 和更早版本。
如需在 .NET 5+ 與 .NET Standard 之間選擇的相關資訊，請參閱本文稍後的 .NET 5+ 和 .NET Standard。
.NET Standard 版本
.NET Standard 已設定版本。 每個新版本都會新增更多 API。 根據 .NET Standard 的特定版本建置程式庫時，它可以在實作該 .NET Standard 版本 (或更高版本) 的任何 .NET 實作上執行。
以較高版本的 .NET Standard 為目標可讓程式庫使用更多 API，但表示它只能用於較新版本的 .NET。 以較低版本為目標會減少可用的 API，但表示程式庫可以在更多位置執行。
選取 .NET Standard 版本
.NET Standard 1.0 在 37,118 個可用的 API 中，有 7,949 個。
| .NET 實作 | 版本支援 |
|---|---|
| .NET 與 .NET Core | 1.0, 1.1, 2.0, 2.1, 2.2, 3.0, 3.1, 5.0, 6.0, 7.0, 8.0, 9.0 |
| .NET Framework | 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7, 4.7.1, 4.7.2, 4.8, 4.8.1 |
| Mono | 4.6, 5.4, 6.4 |
| Xamarin.iOS | 10.0, 10.14, 12.16 |
| Xamarin.Mac | 3.0, 3.8, 5.16 |
| Xamarin.Android | 7.0, 8.0, 10.0 |
| 通用 Windows 平台 | 8.0, 8.1, 10.0, 10.0.16299, TBD |
| Unity | 2018.1 |
如需詳細資訊，請參閱 .NET Standard 1.0。 若為互動式資料表，請參閱 .NET Standard 版本。
要以哪個 .NET Standard 版本作為目標
如果您要以 .NET Standard 為目標，除非您需要支援舊版，否則建議您以 .NET Standard 2.0 為目標。 大部分的一般用途程式庫應該不需要 .NET Standard 2.0 以外的 API，而且 .NET Framework 不支援 .NET Standard 2.1。 所有新式平台都支援 .NET Standard 2.0，而且是以一個目標支援多個平台的建議方法。
如果您需要支援 .NET Standard 1.x，建議您也以 .NET Standard 2.0 為目標。 .NET Standard 1.x 是以一組精細的 NuGet 套件形式散佈，其建立了一個大型的套件相依性圖形，並導致在建置專案時下載大量套件。 如需詳細資訊，請參閱本文稍後的跨平台目標和 .NET 5+ 和 .NET Standard。
注意
從 .NET 9 開始，如果您的專案以 .NET Standard 1.x 為目標，就會發出建置警告。 如需詳細資訊，請參閱.NET Standard 1.x 目標發出的警告。
.NET Standard 版本控制規則
有兩個主要的版本控制規則：
- 累加：.NET Standard 版本就邏輯而言是同心圓：較新的版本會包含來自較舊版本的所有 API。 版本之間並沒有任何重大變更。
- 固定：.NET Standard 在出貨後，版本即凍結。
2.1 之後不會有新的 .NET Standard 版本。 如需詳細資訊，請參閱本文稍後的 .NET 5+ 和 .NET Standard。
規格
.NET Standard 規格是一組標準化的 API。 此規格由 .NET 實作人員維護，具體而言即為 Microsoft (包括 .NET Framework、.NET Core 與 Mono) 和 Unity。
正式成品
正式規格是一組定義 API 的 .cs 檔案，這些 API 是標準的一部分。 dotnet/standard 存放庫中的 ref 目錄 (現已達到) 定義了 .NET Standard API。
NETStandard.Library 中繼套件 (原始檔) 描述定義 (部分) 一或多個 .NET Standard 版本的程式庫集合。
像是 System.Runtime 等指定的元件，其描述：
- .NET Standard 的組件 (僅限其範圍)。
- 適用於該範圍的多個 .NET Standard 版本。
為了更方便閱讀及支援特定開發人員案例 (例如使用編譯器)，已提供衍生成品。
- 以 Markdown 撰寫的 API 清單。
- 以 NuGet 套件散發並由 NETStandard.Library 中繼套件參考的參考組件。
封裝表示
.NET Standard 參考組件的主要散發工具是 NuGet 套件。 傳遞實作的方法有許多種，各自適合每種 .NET 實作。
NuGet 套件是以一個或多個架構為目標。 .NET Standard 套件是以 ".NET Standard" 架構為目標。 您可以使用 netstandard 壓縮目標 Framework Moniker (TFM) (例如，netstandard1.4)，以 .NET Standard 架構為目標。 要在多個 .NET 實作上執行的程式庫應以 .NET Standard 架構為目標。 對大多數的 API 來說，會以 netstandard2.0 為目標，因為提供的 API 數目，超過 .NET Standard 1.6 與 2.0 之間的一倍。
NETStandard.Library 中繼套件會參考定 .NET Standard 的完整一組 NuGet 套件。 若要將 netstandard 設為目標，最常見方式是參考這個中繼套件。 它描述大約 40 種定義 .NET Standard 的 .NET 程式庫和相關 API，並提供其存取權。 您可以參考目標為 netstandard 的其他套件，以存取其他 API。
版本控制
此規格不是單一的，而是一組以線性方式控制版本的 API。 此標準的第一個版本會建立一組基準 API。 後續版本會新增 API，並繼承舊版所定義的 API。 沒有任何既定的佈建可從 Standard 中移除 API。
.NET Standard 並非專屬於任何一個 .NET 實作，也不符合任何這些實作的版本配置。
如前面所述，2.1 之後不會有新的 .NET Standard 版本。
將目標設為 .NET Standard
您可以搭配使用 netstandard 架構和 NETStandard.Library 中繼套件，來建置 .NET Standard 程式庫。
.NET Framework 相容性模式
從 .NET Standard 2.0 開始，引進了 .NET Framework 相容性模式。 此相容性模式可讓 .NET Standard 專案可參考 .NET Framework 程式庫，就如同是為 .NET Standard 編譯一般。 並非所有專案都適合參考 .NET Framework 程式庫。例如，像是使用 Windows Presentation Foundation (WPF) API 的程式庫。
如需詳細資訊，請參閱 .NET Framework 相容模式。
.NET Standard 程式庫與 Visual Studio
若要在 Visual Studio 中建置 .NET Standard 連結庫，請確定您在 Windows 上安裝 Visual Studio 2022、 Visual Studio 2019 或 Visual Studio 2017 15.3 版或更新版本。
若在您專案中只需要使用 .NET Standard 2.0 程式庫，也可於 Visual Studio 2015 中執行。 但需要安裝 NuGet 用戶端 3.6 或更新版本。 您可從 NuGet下載頁面，下載 Visual Studio 2015 的 NuGet 用戶端。
.NET 5+ 和 .NET Standard
.NET 5、.NET 6、.NET 7、.NET 8 和 .NET 9 是單一產品，具有一組統一的功能和 API，可用於 Windows 傳統型應用程式以及跨平台主控台應用程式、雲端服務和網站。 例如，.NET 9 TFM 會反映此廣泛的案例：
net9.0此 TFM 適用於隨處執行的程式碼。 在有一些例外狀況下，它只包含跨平台運作的技術。 針對 .NET 9 程式代碼，
net9.0會netcoreapp取代 和netstandardTFM。net9.0-windows這是OS特定TFM的範例，可將OS特定功能新增至參考的所有專案
net9.0。
以 netx.0 為目標與以 netstandard 為目標的時機
針對以 .NET Standard 2.0 或更新版本為目標的現有程式碼，不需要將 TFM 變更為 net8.0 或更新版本的 TFM。 .NET 8 和 .NET 9 會實作 .NET Standard 2.1 和更早版本。 將以 .NET Standard 為目標重定為以 .NET 8+ 為目標的唯一原因，將會是取得更多執行階段功能、語言功能或 API 的存取權。 例如，若要使用 C# 9，您需要以 .NET 5 或更新版本為目標。 您可以多重目標 .NET 和 .NET Standard 來存取較新的功能，而且您的連結庫仍可供其他 .NET 實作使用。
注意
如果您的專案以 .NET Standard 1.x 為目標，建議您將其複位為 .NET Standard 2.0 或 .NET 8+。 如需詳細資訊，請參閱.NET Standard 1.x 目標發出的警告。
以下是針對 .NET 5+ 新程式碼的一些指導方針：
應用程式元件
如果您要使用程式庫將應用程式細分成數個元件，建議您以
net9.0為目標。 為求簡化，最好是將組成應用程式的所有專案保持在相同版本的 .NET 上。 然後，您就可以認為在任何地方都有相同的 BCL 功能。可重複使用的程式庫
如果您要建置打算在 NuGet 上寄送的可重複使用程式庫，請考量觸達與可用功能集之間的取捨。 .NET Standard 2.0 是 .NET Framework 所支援的最新版本，因此，它在相當大型的功能集上提供良好的觸達。 我們不建議以 .NET Standard 1.x 為目標，因為您會將可用的功能集限制為在觸達上增加最少。
如果您不需要支援 .NET Framework，您可以將目標設為 .NET Standard 2.1 或 .NET 9。 建議您略過 .NET Standard 2.1，並直接移至 .NET 9。 大部分廣泛使用的程式庫都會針對 .NET Standard 2.0 和 .NET 5+ 設定多重目標。 支援 .NET Standard 2.0 可為您提供最大觸達，同時支援 .NET 5+ 可確保您可以針對已在 .NET 5+ 上的客戶運用最新的平台功能。
.NET Standard 問題
以下是 .NET Standard 的一些問題，這有助於說明為何 .NET 5 和更新版本是跨平台和工作負載共用程式碼的最佳方式：
新增 API 的速度緩慢
.NET Standard 已建立為所有 .NET 實作必須支援的 API 集，因此對於提議新增 API 有一項檢閱流程。 目標是只標準化可在所有目前和未來 .NET 平台中實作的 API。 結果是，如果某個功能遺漏了特定版本，您可能必須先等候數年，才能將它新增至一個 Standard 版本。 然後，您會需要更長的時間等候較新版本的 .NET Standard 獲得廣泛支援。
.NET 5+ 中的解決方案：當實作某功能時，它已可供每個 .NET 5+ 應用程式和程式庫使用，因為程式碼基底是共用的。 而且，由於 API 規格與其實作之間沒有任何差異，因此您可以利用速度遠比使用 .NET Standard 更快的新功能。
複雜版本控制
API 規格與其實作的分隔會導致 API 規格版本與實作版本之間的複雜對應。 本文稍早所示的資料表以及如何解譯它的指示中，明顯有這種複雜性。
.NET 5+ 中的解決方案：.NET 5+ API 規格與其實作之間沒有區隔。 結果會是簡化的 TFM 配置。 所有工作負載都有一個 TFM 前置詞：
net9.0用於程式庫、主控台應用程式和 Web 應用程式。 唯一的變化是尾碼，其指定特定平台的平台特定 API，例如net9.0-windows。 拜此 TFM 命名慣例之賜，您可以輕鬆地分辨指定的應用程式是否可以使用指定的程式庫。 不需要任何對等的版本號碼資料表，例如 .NET Standard 的版本編號。執行階段不支援平台的例外狀況
.NET Standard 會公開平台特定 API。 您的程式碼可能會在沒有錯誤的情況下進行編譯，而且即使它非可攜，也似乎可攜至任何平台。 當它在沒有指定 API 實作的平台上執行時，您會收到執行階段錯誤。
.NET 5+ 中的解決方案：.NET 5+ SDK 包含預設啟用的程式碼分析器。 平台相容性分析器偵測到在您打算執行之平台上無意間使用了不受支援的 API。 如需詳細資訊，請參閱平台相容性分析器。
.NET Standard 未過時
多個 .NET 實作可以使用的程式庫仍需要 .NET Standard。 建議您在下列案例中以 .NET Standard 為目標：
- 在 .NET Framework 與其他所有 .NET 實作之間使用
netstandard2.0來共用程式碼。 - 在 Mono、Xamarin 和 .NET Core 3.x 之間使用
netstandard2.1來共用程式碼。
