Если .Net Core может работать в Windows, почему вы не можете ссылаться на .Net Core DLL в .Net Framework?

Question

Я понимаю, почему .Net Framework может вызывать проблемы в .Net Core, IE, потому что API, специфичный для платформы Windows, не существует. Но почему вы не сможете напрямую ссылаться на .Net Core как на библиотеку в .Net Framework? Если .Net Core работает в Windows, что мешает приложению .Net Framework использовать .Net Core, как если бы это была библиотека?

Я знаю, что вы можете портировать библиотеку .Net Core в стандартную библиотеку .Net, но у меня такой вопрос: почему .Net Framework не может просто ссылаться на что-либо написанное в .Net Core, так как она в любом случае кроссплатформенная?

Answer 1

В настоящее время в .NET Framework есть не только API, которые недоступны в .NET Core (например, Remoting, хостинг WCF, дополнительные домены приложений), но теперь в .NET Core также есть API, которые недоступны в .NET Framework - включает полезные дополнения к библиотеке базовых классов и множество API на основе Span<T>, которые были добавлены к базовым типам .NET в .NET Core 2.1.

Для создания библиотек, которые можно использовать на обеих платформах, используйте .NET Standard.

Технически, самое большое различие между .NET Framework и .NET Core заключается в том, где (.dll-файлы) платформы действительно имеют свои реализации и определения типов.

Хотя в .NET Framework есть много базовых типов в mscorlib.dll, .NET Core может содержать их внутри System.Runtime.dll или System.Private.CoreLib.dll.

Ссылка на тип всегда включает имя сборки и пространство имен + имя типа. Если в среде, на которой вы работаете, System.Object определено в mscorlib, но приложение ссылается на [System.Runtime]System.Object, загрузка может быть невозможна.

.NET Core 2.0 приложил усилия, по крайней мере, для предоставления серверов пересылки типов, чтобы ссылки перенаправлялись на правильные сборки. Таким образом, совместимость .NET Framework может перенаправлять [mscorlib]System.Object на [System.Runtime]System.Object при загрузке сборок .NET Framework. (см. Оболочка совместимости, используемая в .NET Standard 2.0 )

То же самое может не работать наоборот. Хотя более новые версии .NET Framework предоставляют множество таких же сборок (реализованных с помощью переадресации типов), которые использует .NET Core, он гарантирует только совместимость с .NET Standard. Если вы ориентируетесь на более старые версии .NET Framework, дополнительные библиотеки пересылки типов будут добавлены в выходные данные сборки для обеспечения этой совместимости (см. Почему мой пакет .NET Standard NuGet вызывает так много зависимостей? ).

Это может в какой-то степени включить загрузку некоторых DLL-файлов .NET Core в .NET Framework, но нет гарантии, что это может работать. Сбой произойдет, если dll использует API, недоступные в .NET Framework, но также может произойти сбой, когда он ссылается на тип с именем сборки, которое недоступно.

Обратите внимание, что это относится только к загрузке DLL-файлов. Ссылки между проектами потерпят неудачу, поскольку инструментарий должен запрещать ссылаться на проекты .NET Core из проектов .NET Framework.

Answer 2

Кроссплатформенность не имеет к этому никакого отношения. .NET Core и .NET Framework - это совершенно разные и отдельные фреймворки. .NET Standard по сути является интерфейсом, который предоставляет общие API. .NET Core 2.0+ реализует .NET Standard 2.0, а также собственные уникальные API. .NET Framework 4.6.1+ также реализует .NET Standard 2.0, а также собственные уникальные API. Технически, для любого из них вы можете ссылаться только на библиотеку, предназначенную для .NET Standard или предназначенную для той же самой платформы (.NET Core для .NET Core и .NET Framework для .NET Framework).

Однако, поскольку существует так много библиотек .NET Framework, многие из которых полностью совместимы с .NET Standard, но не были обновлены для конкретной цели .NET Standard, Microsoft по существу сделала исключение в компиляторе, чтобы разрешить Вы должны ссылаться на библиотеки .NET Framework в вещах, совместимых с .NET Standard 2.0, таких как .NET Core 2.0. Тем не менее, когда вы делаете это, вы получаете предупреждение о том, что библиотека на самом деле может быть несовместимой. Например, если он использует какой-либо из API-интерфейсов, уникальных для .NET Framework, ваше приложение будет взорвано при нацеливании на .NET Core. Разработчик должен проверить и убедиться, что библиотека совместима.

Короче говоря, тот факт, что вы можете ссылаться на библиотеки .NET Framework в проектах .NET Core, обманчив. По сути, это относится к библиотеке .NET Framework так, как будто это библиотека .NET Standard, которая в большинстве случаев работает нормально. Тем не менее, нет никакого специального разрешения для обратного хода.

Answer 3

Совместимость: .NET Core поддерживает не все функции и функциональные возможности, предоставляемые последней версией .NET Framework. Но его можно использовать как подмножество .NET Framework. Также .NET Core является по-прежнему совместим с .NET Framework через .NET Standard библиотека . Следовательно, разработчики все еще могут запускать приложения разработан с .NET Framework после обновления до .NET Core.

Пожалуйста, пройдите это, прежде чем объединить эти две структуры:
В чем разница между .NET Core, .NET Framework и Xamarin?
.NET Core, .NET Framework, Xamarin - «ЧТО И КОГДА ИСПОЛЬЗОВАТЬ»
Разница между .Net Core и .Net Framework
.NET Core против .NET Framework: Как выбрать .NET Runtime для приложения