Почему System.Security.Cryptography.Xml не является частью.NET Standard 2.0?
Меня немного смущает тот факт, что почти все типы из пространства имен System.Security.Cryptography являются частью.NET Standard 2.0, но для System.Security.Cryptography.Xml необходимо получить зависимость от пакета расширения с тем же именем.
Может кто-нибудь объяснить, пожалуйста, здесь трудности? Если проблема была просто не хватает людей и времени, есть ли планы включить его в следующие версии.NET Standard?
1 ответ
У меня складывается впечатление, что вы думаете, что все идет в нестандарт, если они "могут", но на самом деле это больше похоже на то, что они переходят в нетстандарт, если они "должны".
Хотя это не фактический процесс, хорошая модель:
- Правило 0: если тип указан в спецификации ECMA-335, он относится к стандартному стандарту.
- Эти типы имеют специальное взаимодействие с их средой выполнения (clr.dll, coreclr.dll, libcoreclr.so и т. Д.) И, таким образом, не могут быть определены с помощью пакета NuGet.
- Правило 1: если "основополагающий" тип имеет смысл (почти?) Во всех операционных средах, но лучше всего предоставляется / поддерживается системными библиотеками, он, вероятно, принадлежит стандарту netstand (поскольку его трудно доставить эффективно через NuGet).
- Все реализации криптографического алгоритма находятся в этом ведре
- Сеть тоже
- Глобализация тоже
- Правило 2: если тип нужен типу, уже находящемуся в нестандартном, он должен быть в нестандартном.
- Криптография базовых классов
- Поток
- Ладно, почти все из netstandard
- В качестве примера эволюции: текущие предлагаемые изменения для netstandard3.0 включают определение методов (ReadOnly)Span и (ReadOnly)Memory, которые.NET Core добавил в существующие типы netstandard, что означает, что (ReadOnly)Span и (ReadOnly)Memory будут нужно перейти от "в нестандартном" к "в нестандартном".
Вещи, которые определены в netstandard, требуют совместимой реализации, чтобы определить все вещи в ней (хотя " throw new PlatformNotSupportedException(); "это легальная реализация чего-либо). Поэтому.NET Framework, .NET Core, Mono, Xamarin, Unity (и любые другие, которые я не могу придумать) должны определять что-то одно. Иногда код разделяется между этими средами выполнения, но у каждого есть своя функциональная реализация, и исправление ошибки в одном из них требует исправления ошибки во всех 5+ (или, по крайней мере, выпуска обновления для всех 5+).
С другой стороны, когда функциональность может быть предоставлена исключительно с точки зрения уже имеющихся в netstandard вещей, эти вещи хорошо подходят для размещения на NuGet, и одна и та же DLL может быть загружена во все 5+ сред выполнения и работать правильно. Когда ошибка исправлена, она исправляется везде 1,2. Много добра было у всех. В этих библиотеках используется 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.