我对命名空间中的几乎所有类型System.Security.Cryptography
都是 .NET Standard 2.0 的一部分这一事实感到有些困惑,但对于System.Security.Cryptography.Xml来说,需要依赖同名的扩展包。
有人可以在这里解释一下困难吗?如果问题只是没有足够的人员和时间,是否有计划将其包含在 .NET Standard 的下一版本中?
我对命名空间中的几乎所有类型System.Security.Cryptography
都是 .NET Standard 2.0 的一部分这一事实感到有些困惑,但对于System.Security.Cryptography.Xml来说,需要依赖同名的扩展包。
有人可以在这里解释一下困难吗?如果问题只是没有足够的人员和时间,是否有计划将其包含在 .NET Standard 的下一版本中?
我的印象是,您认为如果“可以”,事情就会进入 netstandard,但实际上,如果他们“必须”,它们更像是进入 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 包发布。