Совместимая прокладка, используемая .NET Standard 2.0

Обзор (пример).NET Standard 2.0 говорит, что в нем теперь используется какая-то совместимость, которая устраняет проблему совместимости библиотеки сторонних производителей, Таким образом, вы можете использовать стороннюю библиотеку с .NET Standard до тех пор, пока она не будет использовать какой-либо API, который нет в .NET Standard.

Что не ясно,

Как работает эта прокладка? любые недостатки?

Как проверить, поддерживается ли сторонняя библиотека? Просто добавив его в проект, а затем попытавшись скомпилировать?

Ответ 1

Это работает, создавая все необходимые библиотеки, на которые ссылаются классические библиотеки .NET.

например. в .NET Core реализация Object или Attribute определена в System.Runtime. При компиляции кода сгенерированный код всегда ссылается на сборку и тип = > [System.Runtime]System.Object. Однако классические .NET-проекты ссылаются System.Object на mscorlib. При попытке использовать классическую сборку .NET на .NET Core 1.0/1.1 это обычно приводит к тому, что типы не найдены. В .NET Core 2.0 в mscorlib будут существовать "поддельные" типы, которые среда выполнения знает, как пересылать туда, где фактически реализована реализация.

Вы можете узнать больше о том, как это объединение объединяется в dotnet/стандартном репозитории GitHub, но наиболее важным является сценарий (изображение, взятое из этот репозиторий):

Это показывает, как должен работать сценарий: когда dll-ссылки третьей стороны ссылаются на [mscorlib]Microsoft.Win32.RegistryKey, будет mscorlib.dll, который содержит тип forward на [Microsoft.Win32.Registry] Microsoft.Win32.RegistryKey, поэтому он будет работать, когда присутствует Microsoft.Win32.RegistryKey.dll.

Это также показывает основные недостатки: Реестр - это концепция только для Windows и недоступна на Mac или Linux, поэтому этот конкретный код может не работать на платформах, отличных от Windows. Но если вы используете только те части библиотеки, которые не используют эту функциональность, они могут работать для межплатформенных сценариев.

Другая проблема заключается в том, что даже если API "доступен" для компиляции против и ссылки, он все равно может выбросить PlatformNotSupportedException.

Например, библиотека, которая реализует формат файла для сериализации/десериализации, может работать без изменений, даже если она была создана для .NET Framework 3.5.

Чтобы найти функции API, используемые конкретной библиотекой, .NET Portability Analyzer можно использовать для сканирования DLL и отображения, если библиотека совместимы, а если нет, какие API-интерфейсы блокируются.