为什么System.Security.Cryptography.Xml不属于.NET Standard 2.0？

Question

我对命名空间System.Security.Cryptography中的几乎所有类型都是.NET Standard 2.0的一部分感到困惑，但是对于System.Security.Cryptography.Xml，则需要依赖{{3} }。

有人可以在这里解释困难吗？如果问题仅在于人员和时间不足，是否有计划将其包含在.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的方法，这意味着（ReadOnly）Span和（ReadOnly） ）内存必须从“符合网络标准”变为“符合网络标准”。

---

在netstandard中定义的事物需要兼容的实现来定义其中的所有事物（尽管“ throw new PlatformNotSupportedException();”是任何事物的合法实现）。因此，.NET Framework，.NET Core，Mono，Xamarin，Unity（以及其他我无法想到的）都需要定义一个东西。有时 code 在这些运行时之间共享，但是每个运行时都有其自己的功能实现。而要修复其中的一个错误，则需要修复所有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软件包发布。}