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

Обзор переноса из .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. Такой код включает такие типы проектов, как:

  • Libraries
  • Инструменты на основе консоли
  • Automation
  • сайты 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 можно использовать различные средства для автоматизации некоторых аспектов обновления. Перенос сложного проекта — это сложный процесс. Средства могут помочь в этом пути.

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

Помощник по модернизации приложений GitHub Copilot

Модернизация приложения GitHub Copilot — это помощник по чату GitHub Copilot, который помогает планировать и обновлять проекты до более новых версий .NET, миграции в Azure, обновления зависимостей и применения исправлений кода. Миграция Azure работает с помощью оценки приложений и кода для .NET

Этот помощник чата поддерживает следующие пути обновления:

  • Обновите проекты с более старых версий .NET до последней версии.
  • Обновите проекты с .NET Framework до последней версии .NET.
  • Модернизация базы кода с помощью новых функций.
  • Перенос компонентов и служб в Azure.

Он также работает с различными типами проектов, такими как:

  • ASP.NET и связанные технологии, такие как MVC, Razor Pages, веб-API
  • Blazor
  • Azure Functions
  • Windows Presentation Foundation
  • Windows Forms
  • Библиотеки классов
  • Консольные приложения

Когда следует использовать:

Используйте приложение GitHub Copilot для модернизации приложений, если требуется опыт работы с использованием ИИ для обновления проектов и зависимостей .NET Framework до современной платформы .NET, охватывающий процесс оценки, планирования, устранения и рекомендации по переносу приложений в Azure.

Оценка приложения и кода для .NET

Оценка кода и приложения Azure Migrate для .NET включает анализ кода и приложений, а также дает рекомендации по планированию облачных развертываний. Это поможет вам уверенно запускать критически важные для бизнеса решения в облаке, предлагая оценку исходного кода, ориентированной на разработчика. Это средство также предоставляет рекомендации и примеры оптимизации кода и конфигураций для Azure, следуя рекомендациям отрасли.

Это средство также используется в обновлении приложения GitHub Copilot для работы с .NET.

Когда следует использовать:

Используйте приложение Azure Migrate и набор инструментов для оценки кода .NET, чтобы оценить и получить рекомендации по миграции существующей базы кода в Azure. Оценка приложения и кода в Azure Migrate по сути является подмножеством опыта по модернизации приложения GitHub Copilot для .NET.

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

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

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

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

Когда следует использовать:

Используйте, когда решение с поддержкой искусственного интеллекта, например модернизация приложений GitHub Copilot, недоступна.

try-convert

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

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

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

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

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

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

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

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

✔️ Сначала рассмотрите свои зависимости. Зависимости должны быть предназначены для .NET, .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 8 в качестве целевой платформы, так как это версия с долгосрочной поддержкой (LTS).

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

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

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

См. также

  • Last updated on