Анализ зависимостей для переноса кода из .NET Framework в .NET

Чтобы определить неподдерживаемые сторонние зависимости в проекте, необходимо сначала разобраться с зависимостями. Внешними зависимостями являются пакеты NuGet или файлы .dll, на которые вы ссылаетесь в своем проекте, но не собираете.

Перенос кода в .NET Standard 2.0 или более ранней версии гарантирует, что его можно будет использовать как с .NET Framework, так и с .NET. Но если вам не нужно использовать библиотеку с .NET Framework, рекомендуется ориентироваться на последнюю версию .NET.

Перенос пакетов NuGet в PackageReference

.NET не может использовать файл packages.config для ссылок NuGet. Как .NET, так и .NET Framework могут использовать PackageReference для указания зависимостей пакета. Если вы используете файл packages.config для указания пакетов в проекте, преобразуйте его в формат .

Сведения о том, как выполнить миграцию, см. в статье Преобразование packages.config в PackageReference.

Обновление пакетов NuGet

После переноса проекта в формат PackageReference проверьте, совместимы ли пакеты с .NET.

Сначала обновите свои пакеты до последней доступной версии. Это можно сделать с помощью пользовательского интерфейса диспетчера пакетов NuGet в Visual Studio. Скорее всего, новые версии зависимостей пакета уже совместимы с .NET Core.

Анализ зависимостей пакета

Если вы еще не проверили, что преобразованные и обновленные зависимости пакетов работают на .NET Core, существует несколько способов сделать это.

Анализ пакетов NuGet с помощью сайта nuget.org

Вы можете просмотреть моникеры целевой платформы (TFM) на сайте nuget.org в разделе Зависимости страницы пакета.

С помощью этого сайта легко проверить совместимость, однако информация о зависимостях доступна не для всех пакетов.

Анализ пакетов NuGet с помощью обозревателя пакетов NuGet

Пакет NuGet представляет собой набор папок со сборками для конкретных платформ. Проверьте, существует ли папка, которая содержит совместимую сборку внутри пакета.

Проще всего просматривать папки пакета NuGet с помощью инструмента Обозреватель пакетов NuGet. После установки выполните следующие действия, чтобы увидеть имена папок:

  1. Откройте обозреватель пакетов NuGet.
  2. Щелкните Открыть пакет из веб-канала.
  3. Выполните поиск по имени пакета.
  4. Выберите имя пакета в результатах поиска и нажмите кнопку Открыть.
  5. Разверните папку lib в правой части окна и просмотрите имена папок.

Найдите папку с именами, используя один из следующих шаблонов: netstandardX.Y, netX.Y или netcoreappX.Y.

Эти значения — моникеры целевых платформ (TFM), соответствующие версиям .NET Standard, .NET и .NET Core, которые совместимы с .NET.

Важно!

При просмотре TFM, поддерживаемых пакетом, обратите внимание, что моникеры TFM, отличающиеся от netstandard*, ориентируются на конкретную реализацию .NET, например .NET 5, .NET Core или .NET Framework. Начиная с .NET 5, моникер net* (без заданной операционной системы) фактически заменяет netstandard* как net*. Например, net5.0 ориентируется на область API .NET 5 и поддерживает разные платформы, но net5.0-windows ориентируется на область API .NET 5, реализованную в операционной системе Windows.

Режим совместимости .NET Framework

Анализ пакетов NuGet может показать, что они предназначены только для платформы .NET Framework.

Начиная с .NET Standard 2.0, доступен режим совместимости .NET Framework. Этот режим совместимости позволяет проектам .NET Standard и .NET Core ссылаться на библиотеки .NET Framework. Создание ссылок на библиотеки .NET Framework не работает для всех проектов, например, если библиотека использует API WPF, то делает возможным разблокировку множества сценариев переноса.

Ссылаясь в своем проекте на пакеты NuGet, ориентирующиеся на .NET Framework, например Huitian.PowerCollections, вы получаете предупреждение об откате пакета (Huitian.PowerCollections), как в следующем примере:

NU1701: Package ‘Huitian.PowerCollections 1.0.0’ was restored using ‘.NETFramework,Version=v4.6.1’ instead of the project target framework ‘.NETStandard,Version=v2.0’. This package may not be fully compatible with your project.

Это предупреждение отображается при добавлении пакета и каждый раз при выполнении сборки, чтобы вы обязательно протестировали этот пакет в своем проекте. Если проект работает надлежащим образом, можно отключить это предупреждение, изменив свойства пакета в Visual Studio или путем редактирования файла проекта в привычном редакторе кода вручную.

Чтобы отключить это предупреждение путем редактирования файла проекта, найдите запись PackageReference для пакета, предупреждение для которого требуется отключить, и добавьте атрибут NoWarn. Атрибут NoWarn принимает разделенный запятыми список всех идентификаторов предупреждений. В следующем примере показано отключение предупреждения NU1701 для пакета Huitian.PowerCollections путем редактирования файла проекта вручную:

<ItemGroup>
  <PackageReference Include="Huitian.PowerCollections" Version="1.0.0" NoWarn="NU1701" />
</ItemGroup>

Дополнительные сведения о том, как отключить предупреждения компилятора в Visual Studio, см. в разделе Подавление предупреждений для пакетов NuGet.

Если пакеты NuGet не запускаются в .NET

Если пакет NuGet, от которого зависит ваш проект, не работает в .NET Core, можно предпринять ряд мер:

  • Если проект имеет открытый исходный код и размещается на каком либо ресурсе, наподобие GitHub, вы можете обратиться к разработчикам напрямую.
  • Вы можете обратитесь к автору непосредственно на nuget.org. Найдите пакет и нажмите кнопку Связаться с владельцами в левой стороне страницы пакета.
  • Можно найти другой пакет, который будет выполнять те же функции и работать в .NET Core.
  • Вы можете попытаться создать пакет с аналогичным кодом самостоятельно.
  • Вы можете устранить зависимость от пакета, изменив функциональность приложения, по крайней мере до тех пор пока не станет доступна совместимая версия пакета.

Помните, что обслуживанием проектов с открытым исходным кодом и выпуском пакетов NuGet часто занимаются волонтеры. Они делают эту работу, потому что им важна соответствующая область деятельности, причем безвозмездно, часто в свободное от основной занятости время. Помните об этом, обращаясь к ним за поддержкой при использовании пакетов .NET Core.

Если ни один из этих способов не помог решить проблему, возможно, придется отложить перенос кода в .NET Core на более позднюю дату.

Команда разработчиков .NET хотела бы узнать, поддержку каких библиотек в .NET Core следует реализовать в первую очередь. Сообщить о нужных вам библиотеках можно в электронном сообщении по адресу dotnet@microsoft.com.

Анализ зависимостей, не относящихся к NuGet

Возможно, вы используете зависимость, которая не является пакетом NuGet, например библиотеку DLL в файловой системе. Единственный способ определить переносимость такой зависимости — запустить средство .NET Portability Analyzer. Это средство анализирует сборки, предназначенные для .NET Framework, и идентифицирует API, которые невозможно перенести на другие платформы .NET, например .NET Core. Можно запустить средство в качестве консольного приложения или расширения Visual Studio.

Следующие шаги