2

我对命名空间中的几乎所有类型System.Security.Cryptography都是 .NET Standard 2.0 的一部分这一事实感到有些困惑，但对于System.Security.Cryptography.Xml来说，需要依赖同名的扩展包。

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

4

1 回答 1

3

我的印象是，您认为如果“可以”，事情就会进入 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 将必须从“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 包发布。

于 2018-09-06T16:16:23.613 回答