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

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

Что неясно,

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

а также

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

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

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

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

    Фасад mscorlib

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

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

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

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

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

    Давайте будем гением компьютера.