自从 .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 依然存在三个成绩：
它的版本更新很慢[2]，这意味着你不能轻松地运用最新的特性。
它需求一个解码环[3]来将版本映射到 .NET 完成。
它地下了特定于平台的特性[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)或支持新的数据格式或网络协议，不断对 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 失掉普遍支持。
(责任编辑：admin)