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

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

Что не ясно

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

а также

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

.net-core .net-standard
person Set    schedule 09.06.2017    source источник
comment
@leppie Комментарии не для ответов :)   -  person Alex    schedule 21.08.2018

Ответы (1)


arrow_upward
30
arrow_downward

Это работает путем создания всех необходимых библиотек, на которые ссылаются классические библиотеки .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, но наиболее важный сценарий (изображение взято из этого репозитория):

фасад 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 Portability Analyzer. dll и покажите, совместима ли библиотека, а если нет, какие API блокируют.

person Martin Ullrich    schedule 12.06.2017
comment
Как я могу заметить, совместима ли указанная библиотека .NET Framework с .NET Standard или нет? Это ошибка времени компиляции или ошибка времени выполнения? - person Alex; 21.08.2018