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 回答