如果你正在构建一个 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 是不支持的。
总结