Ответ 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-интерфейсы блокируются.