为什么 System.Security.Cryptography.Xml 不是 .NET Standard 2.0 的一部分？

Question

我有点困惑，因为命名空间 System.Security.Cryptography 中的几乎所有类型都是 .NET Standard 2.0 的一部分，但对于 System.Security.Cryptography.Xml，需要依赖于 extension package by the same name。

有人可以解释一下这里的困难吗？如果问题只是没有足够的人员和时间，是否有计划将其包含在 .NET Standard 的下一个版本中？

Answer 1

我的印象是，您认为“可以”进入 netstandard，但实际上，如果“必须”，则更像是进入 netstandard。

虽然这不是实际过程，但一个好的模型是：

• 规则 0：如果类型在 ECMA-335 规范中被提及，则它属于 netstandard。
  • 这些类型与其运行时（clr.dll、coreclr.dll、libcoreclr.so 等）有特殊的交互，因此不能通过 NuGet 包进行定义。
• 规则 1：如果“基础”类型在（几乎？）所有操作环境中都有意义，但最好由系统库提供/支持，则它可能属于 netstandard（因为很难通过 NuGet 有效地交付）。
  • 所有的加密算法实现都在这个桶中
  • 网络也是如此
  • 全球化也是如此
• 规则 2：如果已经在 netstandard 中的类型需要某个类型，则它需要在 netstandard 中。
  • 密码学基类
  • 流
  • 好的，几乎所有的 netstandard
  • 作为一个演进示例：当前对 netstandard3.0 的提议更改包括定义 .NET Core 添加到现有 netstandard 类型的 (ReadOnly)Span 和 (ReadOnly)Memory-based 方法，这意味着 (ReadOnly)Span 和 (ReadOnly )内存必须从“on netstandard”变为“in netstandard”。

---

netstandard 中定义的事物需要兼容的实现来定义其中的所有事物（尽管“throw new PlatformNotSupportedException();”是任何事物的合法实现）。所以.NET Framework、.NET Core、Mono、Xamarin、Unity（以及其他我想不到的）都需要定义一个东西。有时代码在这些运行时之间共享，但每个运行时都有自己的功能实现；并且修复其中一个错误需要修复所有 5+ 的错误（或者，至少发布所有 5+ 的更新）。

另一方面，当功能可以纯粹根据 netstandard 中已有的东西交付时，这些东西非常适合托管在 NuGet 上，并且可以将相同的 DLL 加载到所有 5 个以上的运行时并正常工作。修复错误后，它会在所有地方得到修复^1,2。所有人都有很多美好。这些库使用 netstandard 版本的 Target Framework Moniker (TFM)，然后它们有效地扩展了 netstandard。唯一的缺点是消费者需要显式添加包引用才能构建。 System.Security.Cryptography.Xml 和 System.Security.Cryptography.Pkcs 都在这个桶中。

---

^{1. .NET Framework（或 Xamarin 等）中已经存在的类型仍然必须在该运行时中独立修复，因为 NuGet 包表示忽略其内容并使用这些平台上的现有实现。}

^{2。对于 .NET Core，当需要将程序集作为运行时的实现细节时，它会包含在 Microsoft.NETCore.App 中，并且 NuGet 包表示忽略其内容并使用该平台上的现有实现，这意味着该错误会得到一次修复，但必须作为 .NET Core 的更新和 NuGet 包发布。}