Часто задаваемые вопросы о разработке приложение для Windows

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

  • Начало работы с разработкой приложений и экосистема Windows.
  • Разработка собственных приложений Windows только с помощью WinUI 3, Windows Presentation Foundation (WPF) и Windows Forms (WinForms).
  • Windows пакет средств разработки программного обеспечения (SDK) и Windows App SDK.
  • Ориентирование на Windows в рамках кроссплатформенной стратегии разработки.
  • Разработка гибридных и веб-приложений с помощью .NET MAUI, Blazor и ASP.NET Core.
  • Как выбрать подход при понимании инвестиций Microsoft.

ландшафт разработки приложений Windows

Где можно найти простой обзор технологий разработки для Windows?

Чтобы получить обзор доступных сегодня вариантов для разработчиков Windows, посмотрите выпуск Windows Dev Chat Как выбрать идеальную платформу для разработки, в котором обсуждаются WinUI 3, .NET MAUI, React Native, Blazor и прогрессивные веб-приложения (PWA). Другие эпизоды можно найти в плейлисте Windows Dev Chat.

Вы также можете обратиться к обзору параметров разработки приложений для разработчиков Windows.

Почему разработка клиентских приложений по-прежнему имеет решающее значение для современной цифровой трансформации в эпоху облачных сервисов?

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

Вот почему клиентские приложения имеют значение:

  • Охват устройств: Клиентские приложения позволяют доставлять ваше приложение напрямую пользователям на выбранных ими устройствах.
  • Шлюз в интеллектуальные службы: клиентские приложения часто являются первым взаимодействием пользователей с вашими службами. Они предлагают широкий интерактивный интерфейс, который позволяет продемонстрировать интеллектуальные функции и отличить продукт от других.
  • Scalability with Cloud Integration: Хорошо интегрированное клиентское приложение может легко синхронизироваться с облачными сервисами, что позволяет доступ к данным в режиме реального времени и простой масштабируемости по мере роста пользовательской базы.
  • улучшенная производительность и лояльность пользователей: продуманное приложение может повысить производительность и поддерживать взаимодействие пользователей с вашим продуктом или службой со временем.

Разработка нативных приложений исключительно для Windows

Что такое Windows App SDK?

Windows App SDK предоставляет независимые компоненты для классических приложений Windows, включая WinUI 3, жизненный цикл приложения, окно, уведомления, ресурсы и текстовые API. Поддерживаются приложения, работающие в Windows 10 версии 1809 и более поздних версиях, в соответствии с жизненным циклом поддержки выпуска Windows и версии Windows App SDK.

Чем разница между Windows App SDK и пакетом SDK Windows?

Оба — это комплекты средств разработки программного обеспечения (SDK), которые позволяют создавать Windows приложения.

Windows App SDK предоставляет компоненты, которые независимо от Windows и работают в поддерживаемых Windows выпусках до Windows 10 версии 1809. Он включает в себя интерфейсы WinUI 3 и API для жизненного цикла приложений, окон, уведомлений, ресурсов, текста и других возможностей.

Windows SDK предоставляет заголовки, библиотеки, метаданные и средства для API операционной системы, таких как Win32, WinRT, COM, DirectX, устройства и возможности оболочки.

Windows App SDK не заменяет пакет SDK Windows. Приложения, которые принимают Windows App SDK, могут продолжать использовать API пакета SDK Windows, а приложения WinUI 3 обычно используют оба.

Я создаю новую команду для разработки приложения только для Windows. Почему следует разрабатывать собственные платформы Windows, такие как WinUI 3, WPF или WinForms?

Ниже приведены некоторые причины выбора собственной платформы Windows для приложения только для Windows:

  • Performance: собственные фреймворки Windows оптимизированы для использования современного оборудования Windows, обеспечивая быстрый и отзывчивый пользовательский опыт.
  • Integration: Windows поставляется с широким спектром API, которые обеспечивают сложные возможности, доступные только в Windows. Собственные платформы обеспечивают глубокую интеграцию с этими функциями и API.
  • Native пользовательский опыт: Нативные фреймворки обеспечивают единообразный опыт на устройствах Windows, гарантируя, что ваше приложение выглядит и работает отлично везде.
  • Автономная поддержка: Собственные платформы поддерживают автономные сценарии, позволяя приложениям функционировать даже без подключения к Интернету.
  • Поддержка и инструменты: Microsoft поддерживает собственные платформы и предоставляет текущие пакеты SDK, документацию, средства отладки и примеры.
Какую платформу следует использовать, чтобы воспользоваться последними инвестициями Microsoft в разработку приложений Windows?

Если вы создаете новое настольное приложение для Windows общего назначения, мы рекомендуем использовать WinUI 3. WinUI 3 — это собственная платформа пользовательского интерфейса, предоставляемая Windows App SDK. Поддерживает классические приложения для Windows и обеспечивает доступ к современным элементам управления Fluent и возможностям платформы Windows.

Можно ли использовать Windows App SDK / WinUI 3 в существующем приложении Windows?

Обратите внимание, что WinUI 3 (платформа пользовательского интерфейса) поставляется с Windows App SDK (платформой разработки платформы Windows).

Пользовательский интерфейс приложения можно перенести в WinUI 3 или использовать Xaml Islands WinUI для размещения Windows App SDK элементов управления в поддерживаемом существующем узле рабочего стола. Устаревшие системы XAML Islands размещают элементы управления UWP XAML и используют различные API.

Элементы Windows App SDK часто можно использовать в настольных приложениях, в зависимости от того, как было создано существующее приложение. Приложения UWP не поддерживаются Windows App SDK.

Это означает, что приложения WPF/MFC/WinForms могут использовать Windows App SDK API, которые не связаны с WinUI 3. К примерам относятся жизненный цикл приложения, окно и уведомления о приложении.

Дополнительные сведения см. в статье Использование Windows App SDK в существующем проекте.

Нужно ли использовать Visual Studio для создания приложений WinUI 3?

Нет. Сборки WinUI 3 XAML используют MSBuild, но можно создать с помощью пакета SDK .NET и текущих шаблонов WinUI 3 из командной строки в другом редакторе. См. краткое руководство по командной строке.

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

Я получаю ошибку "не удалось загрузить DLL 'Microsoft.ui.xaml.dll'" при запуске приложения. Как это исправить?

Эта ошибка обычно возникает в сценариях unpackaged приложения, в которых среда выполнения Windows App SDK не установлена на компьютере. Попробуйте сделать следующее.

  • Если вы используете приложение packaged (рекомендуемый по умолчанию вариант), убедитесь, что вы запускаете через Visual Studio с выбранным профилем запуска MsixPackage (а не обычным профилем исполняемого файла). Шаг упаковки MSIX устанавливает необходимые компоненты среды выполнения.
  • Если вы запускаете неупакованное приложение, зависящее от платформы, установите соответствующую среду выполнения Windows App SDK. Автономное развертывание включает зависимости Windows App SDK.
  • Убедитесь, что проект соответствует модели развертывания. Для обычного неупакованного приложения .NET установка параметра <WindowsPackageType>None</WindowsPackageType> включает автоматическую инициализацию среды выполнения Windows App SDK. Используйте API начальной загрузки непосредственно, только если требуется явный контроль над динамической инициализацией зависимостей.

Дополнительные сведения о требованиях к развертыванию см. в приложенияхDeploy, использующих Windows App SDK.

Какова разница между WinUI 3 и WinUI 2 для UWP?

WinUI 3 — это текущая платформа пользовательского интерфейса Microsoft для классических приложений Windows и поставляется в рамках Windows App SDK.

WinUI 2, также называемый WinUI для UWP, — это библиотека управления и стилизации для приложений UWP. WinUI 2 и WinUI 3 используют разные пространства имен XAML и не совместимы с двоичными файлами.

При создании приложения с помощью Windows App SDK и WinUI 3 я создаю приложение WinUI?

Да. Приложение WinUI 3 — это самый четкий термин для приложения, пользовательский интерфейс которого использует WinUI 3 и Windows App SDK. Приложение WinUI также часто используется, если из контекста ясно, о чём идёт речь.

Можно ли постепенно обновить приложение UWP с помощью WinUI для элементов управления UWP до WinUI 3, постепенно заменив элементы управления?

Нет. Windows App SDK нельзя использовать в приложениях UWP, а WinUI для UWP нельзя смешать с WinUI 3. См. Миграция с UWP на Windows App SDK.

Насколько трудно перенести приложение UWP в WinUI 3?

UWP и WinUI 3 используют множество концепций XAML, но миграция не является прямым изменением пространства имен. Стоимость зависит в первую очередь от:

  1. Файл проекта и кастомизация MSBuild: объем миграции зависит от степени использования расширенных возможностей MSBuild.
  2. Перенос API .NET: приложения UWP, использующие .NET Native, могут перейти на поддерживаемую в настоящее время версию .NET с Native AOT. Эта модернизация отличается от переноса пользовательского интерфейса в WinUI 3.
  3. Библиотеки компонентов пользовательского интерфейса: Библиотеки должны иметь версии, предназначенные для WinUI 3.
  4. API оконной системы и модели приложений: API UWP, связанные с такими концепциями, как CoreWindow, ApplicationView или GetForCurrentView, требуют замены на аналоги из Windows App SDK или иного подхода для классических настольных приложений.
  5. Проекция языка C++: Если приложение UWP использует замененную проекцию C++/CX, портирует этот код в C++/WinRT.

Дополнительные сведения см. в статье Миграция из UWP в Windows App SDK и в разделе Сопоставление API UWP и Windows App SDK.

Если у меня есть существующее приложение UWP в Магазине, можно ли опубликовать новое упакованое приложение WinUI 3, используя те же идентификаторы?

Да, обновленные приложения можно публиковать без обновления идентификатора приложения. Пользователи старой версии будут обновлены до новой версии. Это относится только к настольным приложениям. Xbox, HoloLens и стандартные приложения центра Surface не могут перенестися в WinUI 3.

Как упаковывать или распространять приложение WinUI 3?

См. статью Общие сведения о развертывании.

Где можно найти руководство по миграции Windows App SDK?

См. Миграция с UWP на Windows App SDK.

Нужно ли использовать разметку XAML, если требуется использовать WinUI 3?

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

  • Переход с UWP на WinUI 3: многие понятия XAML и пользовательского интерфейса переносятся, но пространства имен, модель проекта и некоторые API отличаются.
  • Переход с WPF на WinUI 3: многие понятия переносятся, но набор элементов управления и API отличаются.
Есть ли в Visual Studio визуальный редактор или конструктор интерфейса для WinUI 3?

В данный момент нет. Используйте XAML Горячая перезагрузка, динамическое визуальное дерево, обозреватель динамических свойств и связанные средства среды выполнения для проверки и обновления XAML во время выполнения приложения.

Полное пошаговое руководство по средствам разработки среды выполнения, доступным для WinUI 3, см. в статье о средствах разработки среды выполнения XAML для WinUI 3.

Включает ли Windows App SDK WinUI 3?

Да. WinUI 3 входит в состав Windows App SDK.

Включает ли Windows App SDK WinUI для UWP?

Нет. WinUI для UWP является частью платформы UWP.

Основаны ли WinUI для UWP и WinUI 3 на основе одной технологии?

Пока нет. Хотя WinUI 3 началась с базы кода WinUI для UWP, они являются различными технологиями. Оба являются платформами пользовательского интерфейса на основе XAML, которые работают между .NET и C++, но WinUI для UWP и WinUI 3 несовместимы друг с другом.

Можно ли использовать WinUI 3 без использования Windows App SDK?

Нет. WinUI 3 входит в состав Windows App SDK.

Можно ли использовать WinUI 3 в распаковке приложения?

Да. WinUI 3 и многие API Windows App SDK работают в неупакованных приложениях. Однако для некоторых возможностей Windows требуется идентификатор пакета, а неупакованные приложения, зависящие от платформы, должны инициализировать среду выполнения Windows App SDK. Сравните параметры в разделах «Обзор пакетов» и «Функции, для которых требуется идентификатор пакета».

Какова разница между островами XAML и WinUI 3?

WinUI 3 — это платформа пользовательского интерфейса, включенная в Windows App SDK. XAML Islands — это способ размещения, позволяющий существующему классическому приложению размещать содержимое XAML вместе с пользовательским интерфейсом из другой платформы.

Термин может ссылаться на устаревшие системные XAML-острова, в которых размещаются элементы управления XAML UWP, или на островах WinUI XAML, которые размещают Windows App SDK элементы управления в поддерживаемых узлах настольных компьютеров. API, пространства имён и требования к узлу различаются.

Если я создаю приложение WinUI 3, будет выглядеть современно как на Windows 11, так и на Windows 10?

Элементы управления WinUI 3 используют стили Fluent в поддерживаемых версиях Windows 10 и Windows 11 в упакованных и распакованных приложениях. Некоторые эффекты и поведение операционной системы отличаются по Windows версии. Например, Mica доступен в Windows 11, а в Windows 10 заменяется на сплошной цвет.

Можно ли использовать фоны Mica или Акрил в приложениях, созданных с помощью Windows App SDK?

Да. Desktop Acrylic поддерживается в Windows 10 версии 1809 и более поздних версиях. Мика требует Windows 11 и возвращается к сплошной цветовой теме на Windows 10. Вызовите MicaController.IsSupported или DesktopAcrylicController.IsSupported при выполнении программы перед применением подложки. См. Применение материалов Mica или Acrylic в настольных приложениях для Windows 11.

Где можно найти примеры WinUI 3?

Смотрите пример и ресурсы. Некоторые важные репозитории:

Если я уже инвестировал в WPF, следует ли продолжать использовать WPF или рассмотреть возможность миграции на WinUI 3?

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

Используйте функцию GitHub Copilot upgrade, чтобы оценить и обновить приложение WPF на .NET Framework до современной версии .NET. Просмотрите созданный план и проверьте каждое изменение в приложении.

Если я создам новое приложение WPF, будет ли оно выглядеть устаревшим по сравнению с другими новыми приложениями Windows?

При разработке приложения WPF с .NET 9 или более поздней версии вы можете убедиться, что ваше приложение соответствует простому, современному виду Windows 11. Новая тема Fluent для WPF представляет современную Windows 11 эстетику с интегрированным светлым и темным режимом и системной поддержкой цвета акцента. Это модернизирует внешний вид вашего приложения и обеспечивает полированный, сплоченный пользовательский интерфейс.

Моя команда комфортно создает приложения WinForms, и это соответствует нашим потребностям. Следует ли рассмотреть возможность миграции на WinUI 3 или другую платформу?

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

Команда WinForms продолжает инвестировать в платформу. Последние и текущие работы включают:

  • Асинхронные API формы и диалоговых окон
  • Поддержка темного режима и визуального стиля
  • Улучшения специальных возможностей, поддержки высоких DPI, макета и дизайнера
  • Буфер обмена и DataObject модернизация

Разработка нативных кроссплатформенных приложений

Несколько причин создания кроссплатформенных собственных приложений, предназначенных для Windows?

Если вы нацелены на пользователей на нескольких платформах ОС, создание кроссплатформенных приложений с помощью .NET MAUI или React Native может предложить несколько преимуществ:

  • Достигать: Кроссплатформенные приложения достигают большей аудитории на разных устройствах и операционных системах.
  • Повторное использование кода: Повторное потребление кода на разных платформах сокращает время разработки и затраты. Создание отдельных приложений для Windows, Android, iOS и macOS может быть чрезмерно дорогим.
  • Согласованное взаимодействие с пользователем: Кроссплатформенные платформы помогают обеспечить согласованный внешний вид и чувствовать себя на разных платформах.
  • Интеграция: Кроссплатформенные приложения по-прежнему могут интегрироваться с службами, зависящими от платформы, для предоставления комплексного интерфейса.
Кан я уверен, что приложения .NET MAUI будут работать хорошо на Windows?

При сборке приложения .NET MAUI для Windows результат сборки использует WinUI 3. Во время разработки .NET MAUI предлагает единый интерфейс .NET на разных платформах, но он создает код для конкретной платформы под капотом.

Как .NET MAUI может предоставлять родные API устройств на каждой платформе?

.NET MAUI предоставляет единый интерфейс .NET в Windows, iOS, Android и macOS. Он предлагает кроссплатформенные API для распространенных возможностей, таких как хранилище, сети и датчики устройств. Вы также можете вызывать API для конкретной платформы или предоставлять специализированные реализации для каждой платформы.

Можно ли начать работу с WinUI 3, а затем интегрировать .NET MAUI, если я в конечном итоге хочу использовать кроссплатформенные сценарии?

Не в это время. Хотя .NET MAUI использует WinUI 3 при запуске в Windows, командам, планирующим ориентироваться на несколько платформ, следует начинать с .NET MAUI или React Native для настольных приложений.

Наша команда имеет сильные навыки разработки веб-интерфейсов. Следует ли использовать React Native для настольных компьютеров?

Команды с сильным опытом веб-разработки могут рассмотреть React Native для десктопов. Он включает React Native для Windows и macOS. С помощью подхода "Узнать один раз, писать в любом месте" существующие навыки JavaScript, TypeScript и React можно использовать для создания собственных Windows и приложений macOS.

React Native for Desktop отрисовывает пользовательский интерфейс непосредственно в нативные примитивы, предоставляя нативные возможности производительности и платформенные возможности.

Чтобы начать, см. документацию React Native for Desktop.

Поддерживаются ли другие устройства Windows с использованием React Native для настольных систем?

React Native для Windows поддерживает версии Windows, перечисленные в документации по совместимости. Проверьте поддержку семейства устройств для Версии React Native для Windows, которую вы используете, вместо того чтобы предположить, что поддерживается каждое устройство Windows.

Что мне использовать, если я хочу создать приложения, которые работают на Windows и Xbox?

Для приложения Xbox используйте UWP и учитывайте ограничения UWP, характерные для Xbox. Для разработки игр используйте Пакет средств разработки игр Microsoft.

Что я должен использовать, если хочу создавать приложения, работающие на Windows и Surface Hub?

Для Surface Hub, работающего в стандартной среде Teams Rooms или Surface Hub, используйте приложение UWP, соответствующее требованиям к приложениям Surface Hub. Surface Hub 3 с Windows 11 Pro или Enterprise может запускать поддерживаемые технологии настольных приложений, поэтому UWP — не единственный вариант при такой конфигурации.

Гибридная и веб-разработка

Что такое гибридные приложения и почему я должен рассмотреть возможность создания приложения?

Гибридные приложения смешивают лучшее из разработки веб-приложений и собственных приложений. Их ядро создается с помощью веб-технологий, таких как HTML, CSS и JavaScript, и упаковывается в собственный контейнер, который предоставляет access определенным функциям и оборудованию собственной платформы. Они также могут распространяться через магазины приложений.

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

  • Electron для настольных приложений
  • Ionic для мобильных приложений
  • .NET MAUI Blazor Hybrid для кроссплатформенных приложений
Как создать прогрессивные веб-приложения (PWAs) с ощущением родного приложения на Windows?

См. Разработка веб-приложений на Windows и Обзор прогрессивных веб-приложений.

Что такое гибридное приложение .NET MAUI Blazor?

С помощью .NET MAUI приложения Blazor могут работать изначально на Windows, iOS, Android и macOS. Это позволяет создавать гибридные клиентские приложения, которые объединяют Blazor и .NET MAUI компоненты в одном клиентском приложении с полным доступом к возможностям собственной платформы.

Дополнительные сведения см. в ASP.NET Core Blazor Hybrid.

Веб-компоненты гибридного приложения .NET MAUI должны быть созданы с помощью Blazor?

Нет. Начиная с .NET 9, .NET MAUI включает элемент управления HybridWebView, который позволяет размещать другие пользовательские интерфейсы на основе JavaScript в собственном приложении.

Это позволяет размещать приложения Angular, React, Vue или другие приложения HTML/JavaScript в приложении .NET MAUI. Гибридный элемент управления обеспечивает взаимодействие между C# и JavaScript, поэтому код C# может вызывать функции JavaScript и наоборот.

Могут ли другие собственные типы приложений размещать гибридные компоненты Blazor?

Да. WPF и приложения WinForms также могут размещать гибридные компоненты Blazor, что позволяет добавлять современный веб-интерфейс в существующие приложения. Это не поддерживается для приложений WPF или WinForms, созданных на платформе .NET Framework.

Должно ли все приложение быть гибридным приложением или может ли я смешивать и сопоставлять собственные и гибридные компоненты?

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

Несколько вариантов создания веб-приложений на основе .NET, которые выглядят отлично в современных браузерах на Windows?

Web apps предлагают самый широкий охват любой клиентской платформы приложений. Варианты создания красивых веб-приложений .NET включают:

  • Приложения ASP.NET Core с Razor Pages
  • ASP.NET Core MVC приложения
  • ASP.NET Core приложения Blazor с вариантами модели размещения:
    • Blazor WebAssembly (платформа для создания веб-приложений)
    • Blazor Server

Теперь модели размещения Blazor можно настроить на уровне компонента, включив такие сценарии, как размещение компонента Blazor WebAssembly в приложении Blazor Server.

Дополнительные сведения см. в документации ASP.NET Core.

Выбор подхода и понимание инвестиций Microsoft

Существует так много опций фреймворков для разработки приложений под Windows! Как выбрать?

Windows — это открытая платформа, которая поддерживает множество технологий. Ниже приведены некоторые критерии, которые помогут вам выбрать платформу:

  • Вы разрабатываете в первую очередь для Windows или для нескольких платформ?
  • Какие языки или навыки у вас уже есть — .NET, JavaScript, что-то еще?
  • Требуется ли вам доступ к Windows api?
  • Какие возможности платформы лучше всего соответствуют требованиям вашего приложения?
  • См . эту таблицу для дополнительных факторов сравнения.

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

Как я могу выбрать оптимальный подход к разработке для моего веб-приложения?

При выборе подхода к разработке веб-приложения следует учитывать следующее:

  • Blazor рекомендуется использовать для создания веб-приложений на .NET. Это позволяет создавать интерфейсные и внутренние серверные приложения с помощью .NET, экономии времени и затрат, а также особенно хорошо для корпоративных приложений.
  • JavaScript web apps по-прежнему имеют смысл, если вы хотите использовать существующие навыки JavaScript или необходимо интегрировать с установленными библиотеками или фреймворками JS.
  • Существующие приложения, использующие старые платформы, такие как веб-формы, MVC или Razor Pages, остаются поддерживаемыми и могут продолжать разрабатываться и поддерживаться.
Кто создает приложения с помощью WinUI 3 сегодня?

Microsoft Фото является одним из документированных примеров. Приложение перенесено из UWP в Windows App SDK и продолжает использовать WinUI 3. Дополнительные сведения об архитектуре и миграции см. в разделе Microsoft Фотографии: миграция с UWP на Windows App SDK.

Кто создает приложения .NET MAUI сегодня?

Организации используют .NET MAUI для создания кроссплатформенных приложений для Android, iOS, macOS и Windows. См. примеры в разделе .NET «Истории клиентов».

Who создает приложения WPF сегодня?

Большая часть пользовательского интерфейса Microsoft Visual Studio построена с помощью WPF. Сама интегрированная среда разработки Visual Studio является основным примером сложного высокопроизводительного приложения WPF.

Кто создает приложения Blazor сегодня?

Система авиакомпаний FlightPulse от GE Digital использует Blazor для конфигурации серверной части интерфейса, с которым взаимодействуют пилоты, предоставляя пилотам данные датчиков и аналитику напрямую для повышения безопасности и эффективности.

Дополнительные сведения о клиентах Blazor на сайте .NET.

Выбор языка (.NET и C++)

Следует ли использовать C# или C++ для приложения Windows?

В большинстве случаев используйте C# (.NET). C# предлагает более быструю разработку, безопасность памяти, богатые библиотеки и отличные инструменты. Большинство приложений Windows, включая WinUI 3, WPF, WinForms и .NET MAUI приложения, лучше всего создавать с помощью C#.

Используйте C++ при необходимости прямого доступа к оборудованию, минимальной нагрузки во время выполнения или взаимодействия с существующими базами кода C++. Распространенные сценарии C++ включают игровые подсистемы (DirectX), драйверы, служебные программы на уровне системы и критически важные компоненты для производительности.

Фактор C# (.NET) C++
Скорость разработки ✅ Быстрее — управляемая память, богатая экосистема ⚠️ Медленнее — ручное управление ресурсами
Производительность среды выполнения ✅Отлично работает с современным .NET (AOT, Span<T>) ✅ Наилучший вариант — без пауз GC
Безопасность памяти ✅ Сбор мусора ⚠️ Вручную — риск утечки и уязвимостей
доступ к API Windows ✅ С помощью проекции C#/WinRT ✅ С помощью проекции C++/WinRT
Поддержка WinUI 3 ✅ Полная поддержка ✅ Полная поддержка с помощью C++/WinRT
Кросс-платформенность ✅.NET работает в Windows, Linux, macOS ✅ С платформенно-специфичным кодом
лучше всего подходит для Бизнес-приложения, CRUD, службы, приложения с большим количеством пользовательского интерфейса Игры, драйверы, системные средства, низкая задержка

Вы также можете сочетать оба подхода: создать приложение на C# и вызывать критически важный для производительности нативный код через P/Invoke (CsWin32) или компонент C++/WinRT.

Как вызвать API Win32 из C#?

Используйте CsWin32, генератор источника, который создает типобезопасные подписи P/Invoke во время сборки. Вы добавляете пакет NuGet, перечисляете необходимые Microsoft.Windows.CsWin32 API-интерфейсы в NativeMethods.txt файле и вызываете их с помощью созданного PInvoke класса.

CsWin32 заменяет объявления [DllImport], написанные вручную, и работает в любом проекте C#, включая WinUI 3, WPF, WinForms и консольные приложения. Пошаговое руководство см. в статье Вызов API Win32 из приложения Windows на C# (CsWin32).

Что такое C++/WinRT и когда следует использовать его?

C++/WinRT — это стандартная проекция языка C++17 для среда выполнения Windows API. Используйте его при создании приложений Windows в C++, использующих или создающих API WinRT. Он заменяет C++/CX и библиотеку шаблонов C++ среда выполнения Windows C++ (WRL).

Выберите C++/WinRT, когда:

  • Вы создаете приложение WinUI 3 на C++
  • Необходимо создать компоненты среда выполнения Windows, потребляемые другими языками
  • Вы переносите код из C++/CX
Что такое C#/WinRT и когда мне нужно?

C#/WinRT предоставляет поддержку проекции WinRT для C#. В большинстве случаев вы не взаимодействуете с ним напрямую — .NET приложения, предназначенные для Windows автоматически получают доступ к API WinRT через моникеры целевой платформы (TFM). Вам потребуется C#/WinRT, в частности, при разработке компонентов среда выполнения Windows на C# или при создании сборок взаимодействия для сторонних компонентов WinRT.

Упаковка, развертывание и обновления

Какова разница между приложениями, которые упакованы, неупакованные и упакованы с внешним расположением?

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

См. Обзор упаковки с требованиями и компромиссами.

Требуется ли идентификатор пакета?

Он зависит от Windows функций, которые использует ваше приложение. Идентификатор пакета требуется для таких сценариев, как упакованные фоновые задачи, целевые объекты общего доступа, автозапускаемые задачи, пользовательские расширения пакета для контекстного меню, сопоставления типов файлов и протоколов, заданные в манифесте, а также многие API Windows AI. Push-уведомления в Windows App SDK поддерживают ограниченные сценарии работы на переднем плане без идентификатора, однако для фоновой доставки и COM-активации требуется идентификатор. WinUI 3 и локальные уведомления приложения могут работать без идентификатора пакета.

См. функции пакета, требующие удостоверения. Если вам нужен идентификатор, но необходимо сохранить имеющийся установщик, рассмотрите вариант упаковки с внешним расположением.

Какова разница между зависимым от платформы и автономным развертыванием?

Приложение, зависяющее от платформы, использует пакеты среды выполнения Windows App SDK, установленные отдельно на устройстве. Это сокращает размер развертывания приложения и позволяет установленной платформе получать обновления обслуживания. Самодостаточное приложение включает в себя зависимости Windows App SDK, что увеличивает размер развертываемого пакета и возлагает на издателя приложения ответственность за распространение обновлений обслуживания Windows App SDK вместе с новыми версиями приложения.

API, зависящие от дополнительных пакетов MSIX, таких как пакет Singleton, могут требовать отдельных проверок развертывания или среды выполнения даже в автономном приложении. Упаковка и развертывание среды выполнения являются отдельными решениями. См. статью с общими сведениями о развертывании пакета SDK для приложений для Windows.

Будет ли приложение WinUI 3 автоматически обновляться для конечных пользователей?

Приложение WinUI 3 можно распространять через Microsoft Store, файл .appinstaller, пакет MSI или установочный исполняемый файл. Пакеты из Microsoft Store можно обновлять через механизм обслуживания Microsoft Store, в зависимости от параметров Store и организации. Развертывание .appinstaller поддерживает автоматические обновления только в том случае, если его настройки UpdateSettings предусматривают проверки при запуске или в фоновом режиме. Пакеты развертывания MSI и программы установки должны предоставлять или интегрировать собственный механизм обновления.

Могу ли я использовать Windows App SDK без использования MSBuild?

Да, для некоторых сценариев. В настоящее время для проектов WinUI 3 XAML требуется MSBuild, хотя Visual Studio не требуется и dotnet build может вызывать MSBuild из командной строки. Вы можете использовать не-XAML API Windows App SDK в проектах C++ и CMake через предварительную версию приложение для Windows Development CLI или интегрировать среду выполнения вручную.

Искусственный интеллект Windows

Как мне выбрать между API ИИ в Windows, Foundry Local и Windows ML?

Первые три технологии являются частью Microsoft Foundry на Windows. Их можно объединить друг с другом и с облачными моделями в одном приложении:

  • Используйте API ИИ Windows для готовых к использованию возможностей, моделями и аппаратным ускорением которых управляет Windows.
  • Используйте Foundry Local для обнаружения, скачивания и запуска поддерживаемых моделей языка с открытым исходным кодом и речи локально.
  • Используйте Windows ML для запуска собственных моделей ONNX с использованием провайдеров выполнения для доступного оборудования CPU, GPU и NPU.
  • Используйте Microsoft Foundry, отдельную облачную платформу ИИ, если вам нужны облачные модели, извлечение, централизованное управление или возможности, недоступные на целевом устройстве.

Сравните параметры в разделе "Выбор решения Windows ИИ". Рассмотрим возможности модели, конфиденциальность, подключение, задержку, покрытие оборудования, размер развертывания и эксплуатационные затраты.

Требуется ли для функций ИИ Windows ПК Copilot+?

Не все из них. Для многих API Windows ИИ требуется Copilot+ PC, но некоторые API также поддерживают определенные gpu или ЦП. Foundry Local и Windows ML поддерживают более широкие конфигурации оборудования, в соответствии с текущими требованиями к операционной системе, модели, среде выполнения и поставщику выполнения.

Проверьте таблицу оборудования API Windows ИИ и требования к конкретному API или модели. Определяйте поддержку и готовность модели во время выполнения и предоставляйте резервный вариант без ИИ, на локальной модели или в облаке, если функция недоступна.

Можно ли Windows функции ИИ работать локально и автономно?

Да. Windows API ИИ, Foundry Local и Windows ML могут выполнять вывод на устройстве пользователя, что может снизить задержку и сохранить локальные входные данные. Некоторые модели или поставщики выполнения должны сначала загружаться или подготавливаться и могут требовать подключения к Интернету во время установки или обслуживания. Облачные службы ИИ требуют подключения и отправки данных в службу в соответствии с условиями обработки данных.

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

Могут ли средства ИИ помочь мне создать или модернизировать приложение Windows?

Да. Агенты программирования искусственного интеллекта могут помочь в создании шаблонов проектов, объяснить API, перенести код, создать тесты и диагностировать проблемы сборки. Используйте руководство по разработке для Windows с использованием ИИ для GitHub Copilot, плагина агента WinUI, сервера Microsoft Learn MCP, процессов миграции и тестирования с использованием ИИ.

Просмотрите и протестируйте созданный код, как и любой другой вклад. В частности, проверьте имена API и их версии, возможности пакета, код, критичный с точки зрения безопасности, доступность и любые замены UWP на WinUI 3.

Что следует учитывать перед доставкой функции с поддержкой ИИ?

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

Производительность и оптимизация

Что я могу сделать, чтобы приложение Windows казалось отличным для конечных пользователей?

Ознакомьтесь с разработкой приложений для Windows - лучшие практики и обзором производительности приложений Windows и основных понятий.

Compatibility

Потребуется ли пользователям обновить Windows для использования приложения WinUI 3?

В Windows App SDK есть минимальная совместимая ОС Windows 10 версии 1809, сборка 17763. для поддержки Microsoft требуется поддерживаемый выпуск Windows App SDK с последним обновлением обслуживания и выпуском Windows, версией и каналом обслуживания, который по-прежнему поддерживается. Для отдельных API может потребоваться более новая версия Windows или конкретное оборудование. См. поддержку Windows App SDK и каналы выпуска.

Можно ли использовать Arm64 с приложением WinUI 3?

Да. Создайте собственное приложение Arm64 для повышения производительности и эффективности. Для большой базы кода C++ с зависимостями x64, Arm64EC позволяет постепенно переносить модули. Windows 11 в Arm также может запускать множество существующих приложений x86 и x64 с помощью эмуляции Prism, но следует протестировать производительность и совместимость на репрезентативных устройствах Arm.

Устаревания и миграции

Не рекомендуется ли использовать UWP / WinUI для UWP?

UWP и WinUI 2 официально не являются устаревшими. Visual Studio 2026 поддерживает UWP с современной платформой .NET и Native AOT, а WinUI 2.8 остаётся последней стабильной версией WinUI для UWP. Однако Microsoft рекомендует WinUI 3 и Windows App SDK для новых классических приложений Windows общего назначения.

Поддержка UWP для современного .NET на базе Native AOT стала общедоступной и используется в качестве типа проекта C# UWP по умолчанию в Visual Studio 2026. Перемещение существующего приложения UWP из .NET Native в современные .NET является отдельным шагом модернизации от переноса пользовательского интерфейса в WinUI 3. См. статью "Модернизация приложения UWP с помощью .NET и собственного AOT".

Когда следует перенести приложение UWP или WinUI для UWP в WinUI 3?

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

Приложения, которые хотят воспользоваться последней платформой Windows и .NET инвестиций, должны рассмотреть возможность перехода на WinUI 3 и Windows App SDK. См. Миграция с UWP на Windows App SDK.

Когда не следует переносить приложение UWP + WinUI для UWP на WinUI 3?

Продолжайте использовать UWP, если этого требует целевое устройство или модель приложения, например для приложений Xbox, 2D-приложений для HoloLens или приложений для стандартной среды Surface Hub. Windows IoT Enterprise поддерживает технологии классических приложений, включая Windows App SDK, поэтому целевой объект Интернета вещей не является причиной использования UWP.

Является ли WPF устаревшим?

Нет. WPF поддерживается и продолжает получать улучшения функциональности, производительности, специальных возможностей и стиля Fluent в современных версиях .NET. Это остается хорошим выбором для существующих приложений WPF и для новых приложений, требования которых соответствуют WPF. Для новых классических приложений общего назначения Windows основная рекомендация Microsoft — WinUI 3 с Windows App SDK. См. схему WPF на GitHub.

Не рекомендуется ли WinForms?

Нет. WinForms поддерживается и продолжает получать обновления компонентов. См. дорожную карту Windows Forms на GitHub.

Устарел ли среда выполнения Windows (WinRT)?

Нет. WinRT — это двоичный интерфейс приложения (ABI), который обеспечивает взаимодействие между несколькими языками. WinRT — это эволюция COM, и Windows App SDK предоставляет большую часть функций через API WinRT.

Примечания к релизу

Где можно найти заметки о релизе для Windows App SDK?

См. примечания к выпуску Windows App SDK для стабильных, предварительных и экспериментальных выпусков. На странице "Новые возможности для разработчиков Windows" приведены последние Windows SDK, Windows App SDK, WinUI 3, средства и обновления платформы.

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

  • Last updated on