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

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

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

Дополнительные сведения об изменениях по сравнению с .NET Framework см. в статьях Различия WPF между .NET и .NET Framework и Технологии .NET Framework, недоступные в .NET.

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

.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 или службы Worker Service.

Имейте в виду, что некоторые 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, который предоставляет пакет NuGet Microsoft.Extensions.Configuration. Многие библиотеки, в том числе поставщики ведения журнала, сократили 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