.net - 为什么 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 中定义的内容需要兼容的实现来定义其中的所有内容(尽管“抛出 new PlatformNotSupportedException();”是任何内容的合法实现)。所以.NET Framework、.NET Core、Mono、Xamarin、Unity(以及任何其他我想不到的)都需要定义一个东西。有时，代码在这些运行时之间共享，但每个运行时都有自己的功能实现；修复其中一个错误需要修复所有 5+ 中的错误(或者至少发布所有 5+ 的更新)。

另一方面，当功能可以纯粹根据 netstandard 中已有的东西来交付时，这些东西非常适合托管在 NuGet 上，并且相同的 DLL 可以加载到所有 5 个以上运行时中并正常工作。修复错误后，所有地方都会得到修复^1,2。所有人都拥有很多善良。这些库使用netstandard版本的目标框架名字对象(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 包发布。}