.NET Standard 来日苦短去日长( 五 )
.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() 。