[翻译] .NET Standard 2.1 公布

[翻译] .NET Standard 2.1 公布

原文: Announcing .NET Standard 2.1
校对: Cloud

自从大约一年前发布 .NET Standard 2.0 以来，我们已经向 .NET Core 2.1 发布了两个更新，并即将发布 .NET Core 2.2 。 现在是时候更新 Standard 了，包括一些新的概念以及一些小改进，使您在不同的 .NET 实现里编码生活更轻松。

继续阅读以了解有关此最新版本中新功能的更多信息，以及有关平台支持、治理和编码的信息。

NET Standard 2.1 有哪些新功能？

总的来说，计划在 .NET Standard 2.1 中添加大约 3000 个 API 。其中很大一部分是全新的，
而其他部分则是现有的API，添加到 Standard 中，以便进一步使 .NET 实现一致。

以下是其中的亮点：

• Span<T>。 在 .NET Core 2.1 中，我们添加了 Span<T>，这是一种类似于数组的类型，允许以统一的方式表示托管和非托管内存，并支持切片而无需复制。它是 .NET Core 2.1 中与性能相关的大多数改进的核心。由于它允许以更有效的方式管理缓冲区，因此可以帮助减少内存分配和复制。我们认为Span<T> 应该是一种非常基础的类型，因为它需要运行时和编译器支持才能充分利用。如果您想了解有关此类型的更多信息，请务必阅读 Stephen Toub 关于 Span<T> 的优秀文章。
• 使用 span 的基础 API。虽然 Span<T> 已经作为 .NET Standard 兼容的 NuGet 包（System.Memory）提供，但添加此包不能扩展 .NET Standard 类型的成员去使用 span。例如，.NET Core 2.1添加了许多允许使用 span 的API，如 Stream.Read(Span)。将 span 带入 .Net Standard 的话，添加这些 API 是很重要的一部分。
• 反射 emit。为了提高生产力，.NET生态系统一直大量使用动态功能，如反射和反射 emit。 Emit 通常用作优化性能的工具，以及为代理接口动态生成类型的方法。因此，许多人要求反射 emit 包含在 .NET standard 中。之前，我们试图通过 NuGet 包提供这个，但我们发现无法使用包来模拟这样的核心技术。在 .NET Standard 2.1 中，您可以使用轻量级代码生成（LCG）以及反射 emit。当然，您可能运行在不支持通过解释运行 IL 或使用 JIT 编译它的运行时，因此我们还公开了两个新的功能 API，允许您检查生成代码的能力（RuntimeFeature.IsDynamicCodeSupported）以及是否解释或编译生成的代码（RuntimeFeature.IsDynamicCodeCompiled）。这将使编写可移植的库变得容易得多。
• SIMD。.NET Framework 和 .NET Core 现在已经支持 SIMD 一段时间了。我们利用它们来加速BCL 中的基本操作，例如字符串的比较。我们收到了很多在 .NET Standard 中公开这些 API 的请求，因为这些功能需要运行时支持，因此无法作为 NuGet 包来提供。
• ValueTask 和 ValueTask<T>。.NET Core 2.1 最大的功能是改进了我们支持高性能场景的基础知识，其中还包括提高 async/await 效率。 ValueTask<T> 已经存在，如果操作同步完成, 则允许返回结果，而无需分配新的 Task<T>。在 .NET Core 2.1 中，我们进一步改进了这一点，这使得有一个相应的非泛型 ValueTask 变得很有用，它允许减少分配内存，即使是在必须异步完成操作的情况下也是如此，现在使用类似 Socket 和 NetworkStream 的功能。在 .NET Standard 2.1 中公开这些 API 会使库作者能够作为消费者和生产者从其中受益。
• DbProviderFactories。在 .NET Standard 2.0 中，我们在 ADO.NET 中添加了几乎所有基元类型，以允许 ORM 和数据库实现者进行通信。不幸的是，DbProviderFactories 没有添加在其中，所以我们现在添加它。简而言之，DbProviderFactories 允许库和应用程序在编译时使用特定的ADO.NET 提供程序而不需要知道任何特定类型，方法是在基于名称的已注册 DbProviderFactory 实例中进行选择，例如，可以从配置设置中读取。
• General Goodness. 自从 .NET Core 开源后，我们在基础类库中添加了许多小功能，例如System.HashCode 用于组合 hash code 或 System.String 上的新重载。.NET Core 中大约有800个新成员，几乎所有成员都加入了 .NET Standard 2.1。

有关更多详细信息，您可能需要查看 .NET Standard 2.1 和 2.0 之间的完整 API 差异。您还可以使用 apisof.net 快速检查 .NET Standard 2.1 中是否包含某些 API。

.NET 平台支持

如果您错过了我们的 .NET Core 3.0 和 .NET Framework 4.8 更新，其中已经描述了我们对 .NET Framework 和 .NET Core 的支持，如下所示：

• .NET Framework 是 .NET 的实现，它安装在超过 10 亿台计算机上，因此需要保持尽可能的兼容。因此，它的更新速度要比 .NET Core 慢。即使安全性和小错误修复也会导致应用程序中断，因为应用程序依赖于先前的行为。我们将确保 .NET Framework 始终支持最新的网络协议、安全标准和Windows 功能。

• .NET Core 是 .NET 的开源、跨平台和快速移动版本。由于它的 side-by-side 性质，它可以进行一些无法在 .NET Framework 上冒险进行的修改。这意味着 .NET Core 将随着时间的推移获得 .NET Framework 无法获得的新 API 和语言功能。在 Build 大会中，我们展示了 .NET Core 上文件 API 如何比之前更快。如果我们将这些相同的更改放入 .NET Framework ，我们可能会破坏现有的应用程序，我们不希望这样做。

鉴于 .NET Standard 2.1 中的许多 API 添加需要修改运行时才能有意义，.NET Framework 4.8将保留在 .NET Standard 2.0 上，而不是实现 .NET Standard 2.1 。.NET Core 3.0 以及即将推出的 Xamarin，Mono 和 Unity 版本将更新以实现 .NET Standard 2.1。

需要支持 .NET Framework 客户的库作者应该继续使用 .NET Standard 2.0。实际上，大多数库都可以保留在 .NET Standard 2.0 上，因为新添加的 API 主要用于高级场景。但是，这并不意味着库作者无法利用这些 API，即使他们必须支持 .NET Framework。在这些情况下，他们可以使用多目标来编译 .NET Standard 2.0 和 .NET Standard 2.1。这允许编写可以暴漏更多特性的代码，或者在支持 .NET Standard 2.1 的运行时上提供更高效的实现，同时不放弃 .NET Standard 2.0 提供的更大的支持范围。

有关多目标的更多推荐，请查看跨平台目标的最新文档。

Governance model 治理模式

.NET Standard 1.x 和 2.0 版本专注于揭露现有概念。大部分工作都在 .NET Core 方面，因为该平台从更小的 API 集开始。在前进的道路上，我们通常必须标准化全新技术，这意味着我们需要考虑对所有 .NET 实现的影响，而不仅仅是 .NET Core ，包括在其他社区（如 Mono 或 Unity ）中管理的那些。我们的治理模式已经更新，来考虑所有因素：

.NET Standard 审核委员会。为确保我们不会最终添加无法实现的大量 API，审核委员会将签署有关 .NET Standard 的 API 添加内容。该委员会由 .NET 平台、Xamarin、Mono、Unity 和 .NET Foundation 的代表组成，将由 Miguel de Icaza 担任主席。我们将继续努力根据共识做出决策，并将利用 Miguel 的广泛专业知识和经验来构建 .NET 的实现，并在需要时得到多方的支持。

正式批准流程。.NET Standard 1.x 和 2.0 版本在很大程度上是通过计算现有 .NET 实现的 API 共同来实现的，这意味着 API 集实际上是计算结果。展望未来，我们正在实施一种社区策略：

• 任何人都可以向 .NET Standard 提交 API 添加建议。
• 默认认为已有实现中的成员存在 Standard 中。为了防止意外的分裂，我们将默认认为任何 .NET 实现已经添加的所有成员已经存在在 Standard 中。这里的基本原则是成员级别的分歧是不可取的，除非API 出现问题，否则很可能是一个很好的补充。
• 验收要求：
• • 审核委员会成员的响应。该人将被分配该问题，并且引导这个问题，直至其被接受或被拒绝。如果没有董事会成员愿意响应该提案，将被视为被拒绝。
• • 至少在一个 .NET 实现中稳定实现。这个实现必须授权在与 MIT 兼容的开源许可下。这将允许其他 .NET 实现启动他们自己的实现或只是按原样使用该功能。
• .NET Standard 更新是由计划的，通常会遵循一组主题。我们避免发布大量不属于一组常见方案的微小功能。相反，我们尝试定义一组目标，以描述特定 .NET Standard 版本提供的功能区域类型。这简化了某些库应该依赖于 .NET Standard 的问题。它还使 .NET 实现更容易决定是否值得实现更高版本的 .NET Standard。
• 版本号需要经过讨论，通常它是很重要的。虽然我们不打算进行重大更改，但如果新版本添加了大量API（例如，当我们将 .NET Standard 2.0 中的 API 数量增加一倍时），或者整个开发体验有了相当大的改变，我们将修改 major 版本（就像我们在 .NET Standard 2.0 中添加的.NET Framework 库一样，增加了兼容性模式）。

有关更多信息，请查看 .NET Standard 治理模式和 .NET 标准审核委员会。
For more information, take a look at the .NET Standard governance model and the .NET Standard review board.

总结

.NET Standard 2.1 的定义正在进行中。您可以在 GitHub 上观看我们的进度并提出请求。

如果要快速检查特定 API 是否在 .NET Standard（或任何其他.NET平台）中，可以使用 apisof.net 。您还可以使用 .NET 可移植性分析器检查现有项目是否可以移植到.NET Standard 2.1。

Happy coding!