我有点困惑的是，命名空间System.Security.Cryptography几乎所有类型都是.NET Standard 2.0的一部分，但是对于System.Security.Cryptography.Xml，需要依赖同名的扩展包。
有人可以解释一下这里的困难吗？如果问题只是没有足够的人员和时间，是否有任何计划将其包含在下一版本的 .NET Standard 中？
我的印象是，你认为如果事情"可以"，就会进入netstandard，但实际上，如果它们"必须"，它们更像是进入netstandard。
虽然这不是实际过程，但一个好的模型是：
- 规则 0：如果 ECMA-335 规范中提到了该类型，则它属于 netstandard。
- 这些类型与其运行时(clr.dll、coreclr.dll、libcoreclr.so 等(具有特殊的交互，因此无法通过 NuGet 包合理地定义。
- 规则 1：如果"基础"类型在所有操作环境中(几乎？(都有意义，但最好由系统库提供/提供支持，那么它可能属于 netstandard(因为很难通过 NuGet 有效交付(。
- 所有加密算法实现都在此存储桶中
- 网络，也是
- 全球化也是如此
- 规则 2：如果一个类型被 netstandard 中已有的类型需要，那么它需要在 netstandard 中。
- 加密基类
- 流
- 好的，几乎所有的网络标准
- 举个演进的例子：目前提议的netstandard3.0更改包括定义.NET Core添加到现有netstandard类型的基于(ReadOnly(Span和(ReadOnly(Memory的方法，这意味着(ReadOnly(Span和(ReadOnly(Memory必须从"在netstandard上"变成"在netstandard中"。
在netstandard中定义的东西需要一个兼容的实现来定义它中的所有东西(尽管"throw new PlatformNotSupportedException();"是任何东西的合法实现(。 所以.NET Framework，.NET Core，Mono，Xamarin，Unity(以及我想不出的任何其他东西(都需要定义一个东西。 有时代码在这些运行时之间共享，但每个运行时都有自己的功能实现;修复其中一个中的错误需要修复所有 5+ 中的错误(或者至少发布所有 5+ 的更新(。
另一方面，当功能可以纯粹根据 netstandard 中已有的东西来交付时，这些东西非常适合托管在 NuGet 上，并且相同的 DLL 可以加载到所有 5+ 运行时中并正常工作。 修复错误后，它会在1,2处得到修复。 所有人都有很多善良。 这些库使用网络标准版本的目标框架名称(TFM(，然后有效地扩展网络标准。 唯一的缺点是使用者需要显式添加包引用来构建。System.Security.Cryptography.Xml和System.Security.Cryptography.Pkcs都在这个存储桶中。
1. .NET Framework(或 Xamarin 等(中已有的类型仍然必须在该运行时中独立修复，因为 NuGet 包说要忽略其内容并使用这些平台上的现有实现。
2. 对于 .NET Core，当程序集需要作为运行时的实现详细信息时，它会包含在Microsoft.NETCore.App中，并且 NuGet 包说忽略其内容并使用该平台上的现有实现，这意味着该错误得到修复一次，但必须作为 .NET Core 的更新和 NuGet 包发布。