.NET Standard停止更新，它将何去何从？( 四 ) _.NET

如果你要构建一个 Blazor WebAssembly 应用程序，则不必这样做，因为Microsoft.NET.Sdk.BlazorWebAssembly SDK 会自动执行此操作。
.NET 5 作为.NET Standard 和.NET Core 的组合.NET 5 及其后续版本将是一个单一代码库，它支持桌面应用、移动应用、云服务、网站以及未来.NET 将会运行的任何环境。
你可能会认为“等等，这听起来不错，但是如果有人想创建一个全新的实现该怎么办” 。这也是可以的。但实际上没有人会从头开始。这样的实现很可能是当前代码库（ dotnet/runtime ）的分支。例如，Tizen（三星用于智能设备的平台）使用了一个经过少量改动的.NET Core，并且在顶层使用了一个三星定制的应用模型。
分叉保留了合并关系，维护人员可以从不受其更改影响的 BCL 创新中受益，从而继续从 dotnet/runtime 仓库中拉取新更改。这与 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 能够并行安装，因此新版本的采用速度相当快，其中 LTS 版本最为流行。实际上，.NET Core3.1 是有史以来普及最快的.NET 版本。

文章插图
.NET 5 时间表
可以预计每次交付时，我们都会一并更新所有框架名称。例如，计划可能是这个样子：

文章插图

换句话说，你基本上可以指望：无论我们在 BCL 中所做的创新如何，无论它们运行在哪个平台上，你都将能在所有应用模型中使用它。这也意味着，只要运行最新版本的.NET，就始终可以在所有应用模型中使用为最新的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 ），称为browser和browser-wasm 。它们允许包作者以浏览器中的 WebAssembly 为目标时部署不同的二进制文件。这对于需要事先编译为 Web 程序集的原生代码特别有用。

如上所述，我们标记了浏览器沙箱中不支持的 API，例如System.Diagnostics.Process 。如果你是从浏览器应用中使用这些 API，则会收到警告，告知你不支持该 API 。
总结net5.0适用于在各种平台上运行的代码。它合并并替换了netcoreapp和netstandard名称。我们还有特定于平台的框架，例如net5.0-windows（以及后来的net6.0-android和net6.0-ios）。
由于标准与其实现之间没有区别，因此你可以比.NET Standard 更快地利用新特性。而且，由于采用了命名约定，你就能轻松判断谁可以使用给定的库，而无需查阅.NET Standard 版本表。