Поделиться через

Обзор переноса из .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, рассмотрите следующие зависимости:

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

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

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

API, специфичные для Windows

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

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

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

Дополнительные сведения см. в статье Использование пакета совместимости Windows для переноса кода на .NET.

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

Режим совместимости .NET Framework появился в .NET Standard 2.0. Режим совместимости позволяет проектам .NET Standard и .NET ссылаться на библиотеки .NET Framework, как будто они были скомпилированы для целевой платформы проекта. Однако некоторые реализации .NET могут поддерживать больший фрагмент .NET Framework, чем другие. Например, .NET Core 3.0 расширяет режим совместимости .NET Framework до Windows Forms и WPF. Ссылки на библиотеки .NET Framework не работают для всех проектов, например если библиотека использует API WPF, но она разблокирует множество сценариев переноса. Дополнительные сведения см. в разделе «Анализирование зависимостей при портировании кода из .NET Framework в .NET».

Ссылка на библиотеки .NET Framework не работает во всех случаях, так как зависит от того, какие API .NET Framework использовались и не поддерживаются ли эти API целевой платформой проекта. Кроме того, некоторые API .NET Framework будут работать только в Windows. Режим совместимости .NET Framework разблокирует множество сценариев переноса, но следует протестировать проекты, чтобы убедиться, что они также работают во время выполнения. Для получения дополнительной информации см. раздел «Анализ зависимостей для переноса кода из .NET Framework на [платформу]».

Изменения целевой платформы в проектах в стиле SDK

Как упоминалось ранее, файлы проекта для .NET используют другой формат, чем .NET Framework, известный как формат проекта в стиле ПАКЕТА SDK. Даже если вы не переходите из .NET Framework в .NET, необходимо обновить файл проекта до последнего формата. Способ указания целевой платформы отличается в проектах в стиле SDK. В .NET Framework <TargetFrameworkVersion> свойство используется с моникером, указывающим версию .NET Framework. Например, .NET Framework 4.7.2 выглядит следующим фрагментом кода:

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

Проект в стиле SDK использует другое свойство для идентификации целевого фреймворка, свойство <TargetFramework>. При нацеливании на платформу .NET Framework моникер начинается с net и заканчивается версией .NET Framework без каких-либо точек. Например, имя-моникер для целевого объекта .NET Framework 4.7.2: net472

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

Список всех моникеров целевых объектов см. в разделе "Целевые платформы" в проектах в стиле SDK.

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

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

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

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

  • удаленного взаимодействия

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

    Поскольку удаленное взаимодействие не поддерживается, вызовы к BeginInvoke() и EndInvoke() на объектах делегата приведут к выбросу PlatformNotSupportedException.

  • Безопасность доступа к коду (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. В качестве альтернативы см. CoreWF.

Для получения дополнительной информации об этих неподдерживаемых технологиях см. статью Технологии .NET Framework, недоступные в .NET 6+.

Кроссплатформенная платформа

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

  • Библиотеки
  • Консольные инструменты
  • Автоматизация
  • сайты ASP.NET

Платформа .NET Framework — это компонент только для Windows. Если код использует определенные для Windows технологии или API, такие как Windows Forms и 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. После запуска средства в большинстве случаев приложению потребуется больше усилий для завершения миграции. Это средство включает установку анализаторов, которые могут помочь в завершении миграции. Это средство работает со следующими типами приложений .NET Framework:

  • Windows Forms
  • WPF (Windows Presentation Foundation)
  • ASP.NET MVC
  • Консоль
  • Библиотеки классов

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

try-convert

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

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

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

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

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

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

При переносе приложения в .NET рассмотрите следующие варианты:

✔️ Рекомендуется использовать помощник по обновлению .NET для переноса проектов. Несмотря на то, что это средство находится в предварительной версии, оно автоматизирует большинство действий вручную, описанных в этой статье, и дает отличную отправную точку для продолжения пути миграции.

✔️ Сначала рассмотрите свои зависимости. Зависимости должны быть предназначены для .NET, .NET Standard или .NET Core.

✔️ Выполните миграцию из файла NuGet packages.config к настройкам в файле проекта. Используйте Visual Studio для преобразования package.config файла.

✔️ Рассмотрите возможность обновления до последнего формата файла проекта, даже если вы еще не можете перенести приложение. Проекты .NET Framework используют устаревший формат проекта. Несмотря на то что последний формат проекта, известный как проекты в стиле SDK, был создан для .NET Core и далее, формат также работает с .NET Framework. Наличие файла проекта в последнем формате дает хорошую основу для переноса приложения в будущем.

✔️ Перенаправьте проект .NET Framework по крайней мере на .NET Framework 4.7.2. Это гарантирует доступность последних альтернатив API для случаев, когда .NET Standard не поддерживает существующие API.

✔️ Рассмотрите возможность использования .NET 8, который является выпуском с длительным сроком поддержки (LTS).

✔️ Рекомендуется использовать .NET 6+ для проектов Windows Forms и WPF. Версии .NET 6 и более поздние версии содержат множество улучшений для настольных приложений.

✔️ Рекомендуется использовать .NET Standard 2.0, если вы переносите библиотеку, которая также может использоваться с проектами .NET Framework. Вы также можете настроить вашу библиотеку на многоплатформенность, чтобы она была совместима как с .NET Framework, так и с .NET Standard.

✔️ Добавьте ссылку на пакет NuGet Microsoft.Windows.Compatibility , если после миграции возникают ошибки отсутствующих API. Большая часть поверхности API .NET Framework доступна для .NET через пакет NuGet.

См. также