Общие сведения о переносе кода в .NET Framework из .NET

  • Статья

В этой статье приводятся общие сведения о том, что следует учитывать при переносе кода с .NET Framework в .NET (прежнее название — .NET Core). Перенос в .NET из .NET Framework для многих проектов выполняется относительно просто. Сложность проектов определяет, сколько усилий придется приложить после первоначальной миграции файлов проекта.

Для проектов, в которых модель приложений доступна в .NET (например, библиотеки, консольные приложения и классические приложения), обычно требуются небольшие изменения. Проекты, для которых понадобится новая модель приложения, например при переносе в ASP.NET Core из ASP.NET, требуют больше работы. Многие шаблоны из старой модели приложения имеют эквиваленты, которые можно использовать во время преобразования.

Технологии рабочего стола Windows

Многие приложения, созданные для .NET Framework, используют технологии рабочего стола, такие как Windows Forms или Windows Presentation Foundation (WPF). Как Windows Forms, так и WPF были перенесены в .NET, но остаются технологиями только для Windows.

Перед миграцией приложения Windows Forms или WPF учитывайте следующие зависимости:

  1. Файлы проекта для .NET используют формат, отличный от формата .NET Framework.
  2. Проект может использовать API, который недоступен в .NET.
  3. Некоторые сторонние элементы управления и библиотеки не перенесены в .NET и доступны только для .NET Framework.
  4. В проекте используется технология, которая больше не доступна в .NET.

.NET использует версии Windows Forms и WPF с открытым кодом, а также включает улучшения по сравнению с .NET Framework.

Руководства по переносу классического приложения на .NET 6 см. в одной из следующих статей:

API для Windows

Приложения по-прежнему могут обращаться к собственным библиотекам на платформах, поддерживаемых .NET. Эта технология не ограничивается Windows. Однако если библиотека, на которую вы ссылаетесь, относится строго к Windows, например это user32.dll или kernel32.dll, то код будет работать только в Windows. Для каждой платформы, в которой должно выполняться приложение, необходимо либо найти отдельные версии, либо сделать код достаточно универсальным для запуска на всех платформах.

Приложение, вероятно, использовало библиотеку, предоставленную вместе с .NET Framework, и это следует учитывать при переносе приложения с .NET Framework в .NET. Многие интерфейсы API, которые были доступны в .NET Framework, не были перенесены в .NET, так как они использовали технологию, относящуюся только к Windows, например реестр Windows или модель рисования GDI+.

Пакет обеспечения совместимости Windows предоставляет большую часть поверхности API .NET Framework в .NET с помощью пакета NuGet Microsoft.Windows.Compatibility.

Дополнительные сведения см. в разделе Перенос кода в .NET с помощью пакета обеспечения совместимости Windows.

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

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

Недоступные технологии

В .NET Framework есть несколько технологий, которые отсутствуют в .NET:

  • Домены приложений

    Создание дополнительных доменов приложений не поддерживается. Для изоляции кода используйте в качестве альтернативы отдельные процессы или контейнеры.

  • Удаленное взаимодействие

    Удаленное взаимодействие используется для обмена данными между доменами приложений, которые больше не поддерживаются. Для обычного взаимодействия между процессами можно вместо удаленного применять механизмы межпроцессного взаимодействия, например класс System.IO.Pipes или MemoryMappedFile. В более сложных сценариях рассмотрите такие платформы, как StreamJsonRpc или ASP.NET Core (с использованием gRPC или служб веб-API RESTful).

  • Управление доступом для кода (CAS)

    CAS был методом песочницы, который поддерживается .NET Framework, но не рекомендуется в .NET Framework 4.0. Он был заменен прозрачностью безопасности и не поддерживается в .NET. Вместо него применяйте ограничения безопасности, предусмотренные в операционной системе, например виртуализацию, контейнеры или учетные записи пользователей.

  • Прозрачность безопасности

    Подобно CAS, этот метод песочницы больше не рекомендуется для приложений .NET Framework и не поддерживается в .NET. Вместо него применяйте ограничения безопасности, предусмотренные в операционной системе, например виртуализацию, контейнеры или учетные записи пользователей.

  • System.EnterpriseServices

    System.EnterpriseServices (COM+) не поддерживается в .NET.

  • Windows Workflow Foundation (WF)

    WF не поддерживается в .NET 5+ (включая .NET Core). Альтернативный вариант см. в разделе CoreWF.

Дополнительные сведения об этих неподдерживаемых технологиях см. в статье Технологии .NET Framework, недоступные в .NET Core и .NET 5+.

Поддержка разных платформ

.NET (прежнее название — .NET Core) предназначен для кросс-платформенного использования. Если код не зависит от технологий Windows, он может работать на других платформах, таких как macOS, Linux и Android. К ним относятся такие типы проектов, как:

  • Библиотеки
  • Средства на основе консоли
  • Служба автоматизации
  • Сайты ASP.NET

Платформа .NET Framework является компонентом только для Windows. Если в коде используются технологии или API, предназначенные только для Windows, такие как Windows Forms и Windows Presentation Foundation (WPF), код по-прежнему может выполняться в .NET, но не будет работать в других операционных системах.

Возможно, вашу библиотеку или консольное приложение можно использовать на разных платформах без существенных изменений. При переносе кода в .NET учитывайте это и протестируйте приложение на других платформах.

Будущее .NET Standard

.NET Standard — это официальная спецификация для API .NET, которые должны быть доступны во всех реализациях .NET. .NET Standard была создана для того, чтобы повысить согласованность в экосистеме .NET. Начиная с .NET 5 реализован другой подход к обеспечению единообразия, в рамках которого во многих сценариях отсутствует необходимость использовать .NET Standard. Дополнительные сведения см. в статье .NET 5 и .NET Standard.

.NET Standard 2.0 была последней версией, которая поддерживала .NET Framework.

Средства для поддержки переноса

Вместо переноса приложения с .NET Framework в .NET вручную можно использовать различные средства для автоматизации некоторых аспектов миграции. Перенос сложного проекта — это уже непростой процесс. Эти средства помогут вам в этом.

Даже если вы используете средство для переноса приложения, ознакомьтесь с разделом рекомендаций по переносу в этой статье.

Помощник по обновлению .NET

Помощник по обновлению .NET — это средство командной строки, которое можно запускать для различных приложений платформы .NET Framework. Это средство поможет вам в обновлении приложений .NET Framework до .NET 5. После запуска средства в большинстве случаев для завершения миграции приложения потребуются дополнительные действия. Средство включает установку анализаторов, которые могут помочь в завершении миграции. Это средство работает со следующими типами приложений .NET Framework:

  • Windows Forms
  • WPF
  • ASP.NET MVC 3
  • Консоль
  • библиотеки классов;

Это средство использует другие средства, перечисленные в этой статье, и дает рекомендации по процессу миграции. Дополнительные сведения об этом средстве см. в разделе Обзор помощника по обновлению .NET.

try-convert

try-convert — глобальное средство .NET, которое может преобразовать проект или все решение в пакет SDK для .NET, включая перенос настольных приложений в .NET 5. Однако это средство не рекомендуется, если в проекте есть сложный процесс сборки, например пользовательские задачи, целевые объекты или импорты.

Дополнительные сведения см. в репозитории GitHub try-convert.

.NET Portability Analyzer

Анализатор переносимости .NET — это средство, которое анализирует сборки и предоставляет подробный отчет об отсутствующих API-интерфейсах .NET для приложений или библиотек, которые переносятся на заданные целевые платформы .NET.

Чтобы использовать анализатор переносимости .NET в Visual Studio, установите расширение из marketplace.

См. дополнительные сведения об анализаторе переносимости .NET.

Анализатор совместимости платформ

Анализатор совместимости платформы анализирует, используете ли вы API, который выдаст исключение PlatformNotSupportedException во время выполнения. Хотя такая проверка обычно не выполняется при переходе с .NET Framework 4.7.2 и более поздних версий, ее стоит выполнить. Дополнительные сведения об API, вызывающих исключения в .NET, см. в статье API, которые всегда создают исключения в .NET Core.

Дополнительные сведения см.в разделе Анализатор совместимости платформ.

Рекомендации по переносу

При переносе приложения на платформу .NET рассмотрите следующие рекомендации по порядку.

✔️ РЕКОМЕНДУЕТСЯ: используйте помощник по обновлению .NET для переноса проектов. Несмотря на то, что этот инструмент находится на этапе предварительной версии, он автоматизирует большинство выполняемых вручную действий, описанных в этой статье, и предоставляет отличную отправную точку для миграции.

✔️ РЕКОМЕНДУЕТСЯ: сначала проанализируйте зависимости. Зависимости должны быть нацелены на .NET 5, .NET Standard или .NET Core.

✔️ ОБЯЗАТЕЛЬНО: выполните миграцию из файла NuGet packages.config в параметры PackageReference в файле проекта. Используйте Visual Studio для преобразования package.config файла.

✔️ РЕКОМЕНДУЕТСЯ: выполните обновление до последнего формата файла проекта, даже если вы еще не можете перенести приложение. Проекты .NET Framework используют устаревший формат проекта. Хотя новейший формат проекта, известный как проекты в стиле пакета SDK, был создан для .NET Core и более поздних версий, они работают с .NET Framework. Наличие файла проекта в новейшем формате дает хорошее основание для переноса приложения в будущем.

✔️ ОБЯЗАТЕЛЬНО: выберите для проекта .NET Framework целевую платформу .NET Framework версии не ранее 4.7.2. Это обеспечит доступность альтернативных API-интерфейсов последних версий в случаях, когда .NET Standard не поддерживает существующие API-интерфейсы.

✔️ РЕКОМЕНДУЕТСЯ: выберите целевую платформу .NET 5 вместо .NET Core 3.1. Хотя на .NET Core 3.1 распространяется долгосрочная поддержка (LTS), .NET 5 — это последняя версия, а .NET 6 станет версией LTS после выпуска.

✔️ ОБЯЗАТЕЛЬНО: выберите целевую платформу .NET 5 для проектов Windows Forms и WPF. .NET 5 содержит множество улучшений для классических приложений.

✔️ РЕКОМЕНДУЕТСЯ: выберите в качестве целевой платформы .NET Standard 2.0 при миграции библиотеки, которая также может использоваться с проектами .NET Framework. Кроме того, можно выбрать для библиотеки несколько целевых платформ — .NET Framework и .NET Standard.

✔️ ОБЯЗАТЕЛЬНО: добавьте ссылку на пакет NuGet Microsoft.Windows.Compatibility, если после миграции возникнет ошибка отсутствующих API. Большая часть поверхности API .NET Framework доступна для .NET через пакет NuGet.

См. также раздел