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