TL; DR: Вы все еще можете ссылаться (пакеты, которые зависят от). NET Сборки фреймворка, но вы получите ошибку времени выполнения , если вызовете любой код, который полагается на API или библиотеки, которые (пока) не поддерживаются. NET Core. Вы можете обнаружить это с помощью Microsoft . NET Portability Analyzer
Фон
Во-первых, вы правы, что ASP. NET Приложения Core 3.x больше не могут ориентироваться на. NET Framework , как объявлено Microsoft в 2018 году . Эта возможность ранее позволяла ASP. NET Core приложениям вызывать. NET Framework библиотеки и, таким образом, предлагала промежуточное решение для миграции веб-приложений на. NET Core.
Примечание: Поскольку. NET Framework работает только на Windows машинах, записывая ASP. NET базовые веб-приложения, предназначенные для. NET Framework неявно ограничивает выполнение этих приложений на Windows.
Поведение
Даже при таргетинге. NET Ядро, однако, вы все равно можете ссылаться. NET Пакеты и сборки Framework, если вы работаете на компьютере Windows и у вас установлен соответствующий NET Framework. Внутренняя работа здесь немного сложна, но суть в том, что . NET Core будет оценивать. NET Framework собирает , как если бы они были . NET Стандартные сборки . Если вызов API также реализован в среде выполнения. NET Core, он будет работать нормально, но если вызов API исключительно является частью. NET Framework, вы ' будет получено исключение.
Сюрприз! Очень важно подчеркнуть, что это исключение времени выполнения . Вы по-прежнему сможете ссылаться на сборку. NET Framework, записывать вызовы к элементам c и компилировать свой код без каких-либо предупреждений . Но как только вы вызовете код, зависящий от сборки. NET Framework c, вы получите исключение времени выполнения.
Пример
With. NET 3.0, значительная часть библиотек. NET Framework была перенесена в. NET Core. Фактически, это включает большинство System.Drawing библиотек, на которые вы ссылались в качестве примера, хотя есть веских причин, по которым вы можете не захотеть их использовать . Однако, если копнуть немного глубже, существует множество поддерживаемых библиотек. Одним из очевидных примеров является WebConfigurationManager, который можно использовать для доступа к настройкам конфигурации из файлов web.config.
. NET Framework Code
Итак, как Например, допустим, у вас есть следующая функция в библиотеке классов. NET Framework, которая возвращает массив ключей из вашего web.config элемента <AppSetting> s:
public static class Configuration
{
public static string[] GetAppSettings() => System.Web.Configuration.WebConfigurationManager.AppSettings.AllKeys;
}
ASP. NET Основной код
А затем, в ASP. NET основном контроллере, вы открываете конечную точку для получения этих данных:
public class MyController: Controller
{
public IActionResult ApplicationKeys() => Content(String.Join(", ", Configuration.GetAppSettings()));
}
Исключение
В приложении ASP. NET Core 2.x, ориентированном на. NET Framework, это будет работать нормально. Однако в приложении ASP. NET Core 3.x вы получите следующую ошибку времени выполнения при вызове маршрута /My/ApplicationKeys/:
System.TypeLoadException: 'Не удалось тип загрузки 'System.Web.Configuration.WebConfigurationManager' из сборки 'System.Web, Version = 4.0.0.0, Culture = нейтральный, PublicKeyToken = b03f5f7f11d50a3a'. '
Избегайте сюрпризов
Если вы чем-то похожи на меня, это заставит вас невероятно нервничать. Вы бы предпочли получать ошибки времени разработки - или, по крайней мере, предупреждения времени компиляции - как только вы попытаетесь вызвать библиотеку, полагающуюся на неподдерживаемый код. К счастью, Microsoft предлагает . NET Анализатор переносимости , который также доступен как расширение Visual Studio именно для этой цели.
Пример
Если вы запустите анализатор переносимости, например, в приведенном выше примере кода, он выведет электронную таблицу Excel , указав, что T:System.Web.Configuration.WebConfigurationManager равно не поддерживается , например, .NET Core,Version=v3.1 или .NET Standard + Platform Extensions,Version=v2.0.
Примечание: Microsoft предлагала API Analyzer как пакет NuGet, который обещал обеспечить анализ во время разработки в Visual Studio. К сожалению, код не обновлялся два года, а последняя версия - 0.2.12-alpha . По моей оценке, это не помогло выявить проблемы.
Пример проекта
Я собрал образец проекта на GitHub , который демонстрирует вышеуказанное поведение . В него входят следующие проекты:
Оба ASP. NET Основные веб-сайты включают две конечные точки, которые обращаются к одному и тому же. NET Библиотека классов Framework 4.8. Первый - это пример «Hello world», который отлично справится с обоими проектами, поскольку он полагается исключительно на общие API:
http://localhost:5000/Basic/Index
Второй не удастся выполнить в проекте ASP. NET Core 3.1 , поскольку он вызывает устаревший WebConfigurationManager API:
http://localhost:5000/Basic/Configuration
Отказ от ответственности: Это быстрый и грязный репозиторий, который я собрал в подтвердите мое понимание, прежде чем размещать это. Если есть интерес, приведу в порядок и задокументирую. На данный момент, однако, это может оказаться полезным для тех из вас, кому нужно увидеть это в действии.
Благодарности
@ Chris Pratt предлагается отличный ответ , посвященный аналогичному материалу в прошлом году. Это стоит прочитать.