为什么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。

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

• 规则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）基于内存的方法，这意味着（ReadOnly）Span和（ReadOnly）Memory将必须从“网上标准”变为“网上标准”。

---

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包发布。