Совместимая прокладка, используемая .NET Standard 2.0
В обзорах ( пример ) .NET Standard 2.0 говорится, что теперь он использует какую-то совместимость, которая устраняет проблему совместимости библиотеки сторонних разработчиков. Таким образом, вы можете использовать стороннюю библиотеку с .NET Standard до тех пор, пока она не будет использовать какой-либо API, которого нет в стандарте .NET.
Что неясно,
- как эта прокладка работает? любые недостатки?
а также
- Эквивалент AssemblyInfo в ядре dotnet / csproj
- Как упаковать переносимую библиотеку .NET, ориентированную на .NET Core?
- Определение Project.json dnx451 vs .dotnet (4.51)
- Использование app.config в .Net Core
- Как загрузить сборки, расположенные в папке в .net-приложении консоли ядра
- как проверить, поддерживается ли сторонняя библиотека? Просто добавив его в проект, а затем попытавшись скомпилировать?
- Манипулирование изображениями с помощью .NET Core
- JWT на .NET Core 2.0
- Шифрованная конфигурация в ядре ASP.NET
- EF Core Второй уровень ThenInclude missworks
- В чем разница между ASP.NET 5, .NET Core и ASP.NET Core 5?
- Автоматическое ведение версий в Visual Studio 2017 (.NET Core)
- Как получить проекты .NET Core для копирования ссылок NuGet для сборки вывода?
- Вернуть файл в ASP.NET Core Web API
Это работает, создавая все необходимые библиотеки, на которые ссылаются 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, но наиболее важным является сценарий (изображение, взятое из этого репозитория):
Это показывает, как сценарий должен работать: когда ссылка на стороннюю 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-интерфейсы блокируются.