Обзор обновления приложений Windows Forms

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

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

Пример обновления см. в статье Об обновлении приложения Windows Forms до .NET с помощью модернизации GitHub Copilot.

Почему обновление

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

Также важно следить за актуальными версиями .NET. У каждой версии .NET есть определённый срок поддержки, и приложения, работающие на версии, срок поддержки которой истёк, перестают получать обновления безопасности и исправления. Обновите до завершения поддержки, чтобы оставаться защищенным.

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

  • Новые элементы управления, улучшения специальных возможностей и улучшенная поддержка высокого DPI.
  • Улучшенная интеграция с Windows. Некоторые функции, такие как темный режим на Windows 11, доступны только в .NET.
  • Новые возможности языка C# и Visual Basic и улучшенные средства.
  • Богатая экосистема пакетов NuGet, предназначенных для .NET.

.NET выпускает новую основную версию каждый год, чередуя выпуски с долгосрочной поддержкой (LTS) и выпуски со стандартным сроком поддержки (STS):

  • Выпуски LTS поддерживаются в течение трех лет и обычно являются лучшим выбором для рабочих приложений, которые предпочитают стабильность.
  • Выпуски STS поддерживаются в течение 24 месяцев и полезны, если вы хотите использовать новые функции раньше.

Запланируйте периодичность обновления вокруг этих дат, чтобы приложение всегда было в поддерживаемой версии. Текущие поддерживаемые версии и даты окончания поддержки см. в .NET выпусках, исправлениях и поддержке.

Варианты обновления

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

  • От .NET Framework до .NET: наиболее значительное изменение.

    Формат файла проекта, некоторые API и определенные технологии отличаются. Просмотрите предварительные требования, оцените зависимости и запланируйте пробелы API перед началом работы.

    После сборки и запуска приложения на .NET можно при необходимости внедрить новые шаблоны, такие как appsettings.json конфигурация, внедрение зависимостей или облачные службы. Внедрение этих шаблонов отличается от модернизации до .NET и не требуется для завершения обновления. Сведения о идеях и рекомендациях см. в статье "Модернизация после обновления до .NET из .NET Framework".

  • С более старой версии .NET на более новую: менее масштабное обновление.

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

Обновление с .NET Framework до .NET

Обновление с .NET Framework до .NET является наиболее значительным путем обновления и основным фокусом этого раздела.

Important

Хотя .NET — кроссплатформенная технология, настольные приложения Windows для .NET по-прежнему работают только в Windows.

Одно из изменений — формат файла проекта. .NET использует формат проекта в стиле ПАКЕТА SDK, который является более кратким, чем устаревший формат. Вы можете преобразовать файл проекта в формат SDK-style, пока он по-прежнему нацелен на .NET Framework, что уменьшает объём изменений при фактическом переносе и даёт вам лучшую отправную точку для дальнейшей работы.

Не все API .NET Framework доступны в .NET. Некоторые API лишь формально существуют, но во время выполнения выбрасывают PlatformNotSupportedException. Пакет совместимости Windows (Microsoft.Windows.Compatibilityпакет NuGet) заполняет многие из этих пробелов, предоставляя доступ к api Windows, таким как реестр Windows, журнал событий Windows и многое другое. Дополнительные сведения см. в разделе Использование пакета обеспечения совместимости с Windows для переноса кода в .NET.

Некоторые технологии .NET Framework не имеют эквивалента в .NET и требуют альтернативных подходов, таких как домены приложений, безопасность доступа к коду (CAS) и Windows Workflow Foundation. Дополнительные сведения см. в разделе "Недоступные технологии .NET Framework".

Аудит сторонних зависимостей. Элементы управления и библиотеки, предназначенные только для .NET Framework, могут не работать в .NET. Предпочитайте пакеты NuGet, предназначенные для .NET standard 2.0 или .NET напрямую. Для пакетов, которые не были перенесены, найдите альтернативные варианты сообщества или проверьте, охватывает ли пакет совместимости Windows необходимые API.

Обновление между версиями .NET

Переход от одной версии .NET к другой (например, от .NET 9 до .NET 10) обычно меньше, чем модернизация из .NET Framework. Основная задача — обновить свойство <TargetFramework> в файле проекта, указав новый идентификатор целевой платформы. Например, изменение net9.0-windows на net10.0-windows.

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

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

Модернизация приложения GitHub Copilot

Агент модернизации GitHub Copilot — это рекомендуемое средство для обновления Windows Forms и приложений WPF. Это комплексный интерфейс искусственного интеллекта, встроенный в GitHub Copilot, который обрабатывает весь процесс обновления.

Агент следует трехэтапный рабочий процесс:

  • Оценки. Copilot проверяет структуру проекта, зависимости и шаблоны кода. Он определяет критические изменения, проблемы совместимости API, устаревшие шаблоны и общую область обновления. Затем он предлагает вам ознакомиться со стратегическими решениями, такими как порядок обновления и обеспечение совместимости, перед продолжением.

  • Планирование. Copilot преобразует оценку и ваш подтвержденный выбор в подробный план обновления, документируя стратегии обновления, рефакторинг подходов, пути зависимостей и способы устранения рисков.

  • Выполнение. Copilot разбивает план на последовательные задачи с критериями проверки, применяет исправления кода и фиксирует изменения постепенно. Если она сталкивается с проблемой, которую не может решить автоматически, она просит вас помочь и учится на исправлении.

Все состояние обновления хранится в .github/upgrades/ репозитории, чтобы можно было приостановить и возобновить работу между сеансами или переключаться между средами разработки, не теряя ход выполнения.

Агент поддерживает следующие пути обновления:

  • .NET Framework (любая версия) для .NET 8 или более поздней версии
  • .NET Core 1.x–3.x до .NET 8 или более поздней версии
  • .NET 5-7 до .NET 8 или более поздней версии
  • Миграция в службы Azure

Он доступен в Visual Studio 2026, Visual Studio 2022 17.14.16+, Visual Studio Code и GitHub CLI. Чтобы начать обновление в Visual Studio, щелкните правой кнопкой мыши решение или проект в Обозреватель решений и выберите "Модернизировать" или откройте окно Copilot Chat GitHub и введите его@Modernize. В Visual Studio Code откройте панель чата GitHub Copilot и введите @modernize-dotnet.

Сведения о настройке и использовании см. в разделе "Что такое модернизация GitHub Copilot?".

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

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

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

    AppDomain не поддерживается. Используйте AssemblyLoadContext для динамической загрузки сборок, а для обеспечения изоляции используйте отдельные процессы или контейнеры. Некоторые AppDomain элементы API присутствуют, но выдают PlatformNotSupportedException при выполнении.

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

    Технология .NET Remoting не поддерживается. Используйте System.IO.Pipes или MemoryMappedFile для локального IPC, или gRPC и ASP.NET Core для обмена данными между компьютерами. Вызовы BeginInvoke() и EndInvoke() для объектов-делегатов также вызывают исключение PlatformNotSupportedException.

  • Безопасность доступа к коду (CAS)

    Cas не поддерживается и больше не является границей безопасности. Вместо этого используйте границы безопасности уровня ОС, такие как виртуализация, контейнеры или учетные записи пользователей.

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

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

  • Windows Workflow Foundation (WF)

    WF не поддерживается в .NET. Если приложение размещает или использует рабочие процессы, рассмотрите coreWF, порт с открытым исходным кодом среды выполнения Windows Workflow Foundation, предназначенный для .NET.

  • System.EnterpriseServices (COM+)

    System.EnterpriseServices не поддерживается. Приложения, использующие службы COM+, такие как пул объектов, транзакции или безопасность System.EnterpriseServices на основе ролей, необходимо изменить для использования альтернативных вариантов. Для распределенных транзакций рассмотрим System.Transactions. Для сценариев размещения сервисов рассмотрите использование ASP.NET Core или рабочих служб.

Имейте в виду, что некоторые API в этих областях присутствуют в .NET, но во время выполнения выбрасывают PlatformNotSupportedException, а не приводят к ошибке на этапе компиляции. Протестируйте приложение на .NET на раннем этапе миграции, чтобы выявить эти проблемы, прежде чем вкладываться в полноценный перенос.

Перед началом обновления с .NET Framework

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

  • Обновите инструменты.

    Убедитесь, что вы используете версию Visual Studio, которая поддерживает версию .NET, которую вы планируете использовать. Более новые версии пакета SDK включают улучшенную поддержку миграции, улучшенные анализаторы и обновленные шаблоны проектов. Сведения о связи между версиями пакета SDK .NET, MSBuild и Visual Studio см. в разделе "Связь управления версиями" между пакетом SDK .NET, MSBuild и Visual Studio.

  • Целевой объект .NET Framework 4.7.2 или более поздней версии.

    Перенаправьте проект на .NET Framework 4.7.2 или более поздней версии перед переносом. Эта версия предоставляет наиболее широкую область совместимости API с .NET standard 2.0, что снижает количество пробелов API, которые вы столкнетесь во время обновления.

    В Visual Studio щелкните проект правой кнопкой мыши, выберите "Свойства" и измените раскрывающийся список Target Framework на .NET Framework 4.7.2. Перед продолжением перекомпилируйте и исправьте все проблемы.

  • Преобразуйте в формат PackageReference.

    Если проект использует packages.config файл для управления ссылками NuGet, перейдите в PackageReference формат. PackageReference — это современный подход и непосредственно интегрируется в формат проекта в стиле пакета SDK, который будет принят на следующем шаге.

    В обозревателе решений Visual Studio щелкните правой кнопкой мыши packages.config и выберите Преобразовать packages.config в PackageReference. Просмотрите выходные данные миграции и устраните все предупреждения перед продолжением.

  • Преобразовать в формат проекта типа SDK.

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

  • Обновите зависимости NuGet.

    Обновите все пакеты NuGet до последних версий и предпочитайте пакеты, ориентированные на .NET Standard 2.0, а не пакеты, ориентированные только на .NET Framework. Это снижает риск блокировки зависимостей при изменении целевой платформы. Просмотрите заметки о выпуске пакета для любых критических изменений, представленных в более новых версиях.

Все предыдущие предложения гарантируют, что проекты находятся в хорошем состоянии перед обновлением до .NET.

Пакет совместимости Windows

Одна из наиболее распространённых проблем при переносе с .NET Framework — отсутствие API. .NET Standard намеренно исключает технологии, которые не могут работать на всех платформах, таких как реестр Windows, WMI и отражение, поэтому эти API не доступны по умолчанию. Пакет Microsoft.Windows.Compatibility NuGet заполняет этот пробел. Он предоставляет около 20 000 API в следующих областях технологий:

  • реестр Windows;
  • Журнал событий Windows
  • Инструментарий управления Windows (WMI)
  • Счетчики производительности Windows
  • Службы каталогов
  • Списки управления доступом Windows (ACL)
  • Службы Windows
  • Криптография Windows
  • Windows Communication Foundation (WCF)
  • Порты, ODBC, CodeDom и многое другое

Этот пакет основан на .NET Standard 2.0 и особенно полезен при поэтапной модернизации. Это позволяет сначала добиться того, чтобы приложение собиралось и работало на .NET, а затем заняться более глубокой переработкой кода, не переписывая сразу участки кода, использующие API, специфичные для Windows.

Чтобы добавить его в проект, установите Microsoft.Windows.Compatibility пакет NuGet:

dotnet add package Microsoft.Windows.Compatibility

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

Кардинальные изменения

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

Критические изменения делятся на несколько категорий, и не все из них вызывают ошибки во время компиляции:

  • Изменения поведения влияют на работу API во время выполнения. Подпись остается той же, но результат, выбрасываемые исключения или внутреннее поведение меняются. Их труднее всего обнаружить, потому что они не вызывают ошибок сборки.
  • Изменения в двоичной совместимости влияют на то, продолжают ли существующие скомпилированные сборки работать без повторной компиляции. Удаление или изменение общедоступной поверхности API нарушает совместимость двоичных файлов.
  • Изменения совместимости исходного кода требуют изменения исходного кода, прежде чем он успешно компилируется в более новой версии.
  • Изменения совместимости во время разработки влияют на то, как проекты открываются и ведут себя в Visual Studio или других средах разработки.

При переносе из .NET Framework вы пересекаете большой разрыв версий, поэтому список потенциальных изменений больше. При обновлении между версиями .NET (например, с .NET 6 до .NET 9) область является более узкой, но каждая версия между ними может вносить изменения, влияющие на приложение. Просмотрите критические изменения для каждой пропускаемой версии, а не только для целевой версии.

Критические изменения, специфические для Windows Forms, описаны в статье Критические изменения при миграции с .NET Framework на .NET. Отфильтруйте список критических изменений по диапазону версий, через который выполняется обновление, и просмотрите записи, относящиеся к API, которые использует ваше приложение.

Задачи после обновления

После сборки и запуска приложения на .NET выполните несколько задач очистки, чтобы удалить артефакты, оставшиеся после обновления.

Просмотрите пакеты NuGet.

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

Очистите старые артефакты NuGet.

Если в проекте для управления ссылками на пакеты NuGet использовался файл packages.config, после миграции на формат PackageReference он больше не нужен. Удалите его из проекта. Вы также можете удалить локальную packages папку в каталоге проекта или решения. NuGet теперь хранит пакеты в папке .nuget\packages глобального кэша в профиле пользователя.

Обновление System.Configuration ссылок.

Большинство приложений .NET Framework ссылаются на System.Configuration напрямую. После обновления проект может по-прежнему нести эту ссылку. Библиотека System.Configuration считывает данные из файла app.config для конфигурации во время выполнения. В .NET замените его на пакет NuGet System.Configuration.ConfigurationManager, который предоставляет тот же набор API без прямой ссылки на сборку платформы.

Выполните модернизацию после обновления

После запуска приложения на .NET можно использовать современные шаблоны, недоступные в .NET Framework. Эти изменения не требуются для завершения обновления, но они повышают удобство обслуживания и используют активные инвестиции в .NET. Более широкий набор идей см. в разделе "Модернизация" после обновления до .NET из .NET Framework.

Переход с App.config на appsettings.json.

.NET Framework использует App.config для параметров времени выполнения, таких как строки подключения и конфигурация ведения журнала. Приложения .NET вместо этого обычно используют appsettings.json из пакета Microsoft.Extensions.Configuration NuGet. Многие библиотеки, в том числе поставщики ведения журнала, сократили App.config поддержку в пользу appsettings.json. Перенос приложения соответствует экосистеме и упрощает настройку при добавлении новых зависимостей.

App.config файлы продолжают работать в .NET через System.Configuration.ConfigurationManager пакет NuGet, чтобы можно было постепенно перенести файлы. Инструкции см. в разделе "Конфигурация" в .NET.

Замените элемент управления WebBrowser на WebView2 (WPF).

Элемент управления WebBrowser использует Internet Explorer, который больше не поддерживается. WPF для .NET может использовать элемент управления WebView2, основанный на Microsoft Edge, вместо этого. WebView2 предоставляет современный, активно поддерживаемый элемент управления браузером с улучшенной производительностью, безопасностью и поддержкой веб-стандартов.

Добавьте в проект пакет NuGet Microsoft.Web.WebView2. В зависимости от того, какая версия Windows выполняется пользователем, может потребоваться установить среду выполнения WebView2 отдельно. Дополнительные сведения см. в статье "Общие сведения о Microsoft Edge WebView2".

Связанный контент

  • Last updated on