Обзор упаковки

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

Замечание

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

Почему упаковка приложений имеет значение

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

Функции, которым требуется идентификатор пакета

Многие функции Windows работают только в приложениях, которые имеют идентификатор пакета, полученный либо с помощью полной упаковки в MSIX, либо упаковки с внешним расположением файлов (разреженная упаковка). Примеры включают фоновые задачи, push-уведомления, цели общего доступа, пользовательские расширения контекстного меню, сопоставления типов файлов и протоколов на основе манифеста, а также API ИИ в Windows.

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

Подсказка

Если ваше приложение не имеет пакета и вы сталкиваетесь с ошибками E_ILLEGAL_METHOD_CALL или APPMODEL_ERROR_NO_PACKAGE при вызове API Windows, это связано с требованием удостоверения пакета. Ознакомьтесь с упаковкой с внешним расположением (разреженная упаковка) как с решением, минимизирующим трудности.

Чтобы определить во время выполнения, имеет ли ваш процесс идентификатор пакета, используйте GetCurrentPackageFullName. См. раздел "Это упакованный процесс?" в блоге внутри MSIX для канонических примеров C++ и C#.

Упаковка моделей на первый взгляд

Модель Идентификатор пакета Монтажник Магазин, подходящий лучше всего подходит для
Упаковано (MSIX) ✅ Да MSIX заменяет установщик ✅ Да (отправка MSIX) Новые приложения, публикация в магазине, корпоративное управление мобильными устройствами
Упаковка с внешним расположением ✅ Да Ваш существующий установщик ✅ Да (отправка MSI/EXE) Существующие приложения с собственным установщиком, ISV
Распаковка ❌ Нет Установщик MSI или EXE (также: XCopy или скрипт для распространения вне магазина приложений) ✅ Да (отправка MSI/EXE — требуется установщик MSI или EXE с поддержкой автоматической установки) Широкое распределение Win32, внутренние инструменты

Упакованные приложения (MSIX)

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

  • Упакованные приложения обычно выполняются в упрощенном контейнере приложений с файловой системой и виртуализацией реестра (см. раздел AppContainer для устаревших приложений и приложений MSIX AppContainer).
  • Приложения также можно настроить не для запуска в контейнере приложений при необходимости.
  • MSIX используется как для упаковки, так и для установки (см. раздел "Что такое MSIX?").

Упаковка с внешним расположением (малоплотная упаковка)

Упаковка с внешними элементами (также называемые разрежёнными пакетами) позволяет зарегистрировать небольшой пакет с идентификатором вместе с существующим приложением без изменения установщика, расположения двоичных файлов или процесса обновления. Она появилась в Windows 10 версии 2004 (сборка 19041).

Это оптимальный вариант для существующих приложений Win32/WPF/WinForms, которые распространяются через собственный установщик (NSIS, WiX, InstallShield и т. д.) и не хотят заменять его на MSIX. Вы регистрируете упрощенный пакет идентификации, двоичные файлы остаются без изменений, и вы получаете доступ ко всем функциям Windows, управляемым удостоверением пакета.

Функциональность MSIX Внешнее расположение
Заменяет ваш установщик Да Нет
Двоичные файлы внутри пакета Да Нет (внешний)
Магазин, подходящий Да (отправка MSIX) Да (отправка MSI/EXE)
Идентификатор пакета Да Да
Механизм обновления Обновление MSIX Ваш существующий механизм

Полное пошаговое руководство: Идентификация пакета путём упаковки с внешним местоположением

Непакетированные приложения

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

  • Они остаются полностью неограниченными в отношении поверхности API, доступа к файловой системе, доступа к реестру, эскалации привилегий и модели процесса.
  • Установка и обновления зависят от .exe, .msi, пользовательских установщиков, ClickOnce или xcopy.

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

Выбор по сценарию

Сценарий Рекомендуемая модель Сведения
Независимый разработчик, публикующий в Microsoft Store Рекомендуемый пакет (MSIX) MSIX — это рекомендуемый путь — он позволяет управляемые Магазином обновления, разностные загрузки и чистую деинсталляцию. Приложения WinUI 3 упаковываются по умолчанию. Подписывание кода обрабатывается бесплатно в Магазине.Распространение упаковаемого приложения

Приложения Win32 с существующим установщиком MSI или EXE также могут публиковаться в Магазине через путь отправки MSI/EXE, но Магазин не отправляет обновления существующим пользователям— обновления должны обрабатываться приложением или установщиком.
Корпоративное приложение, развернутое с помощью Intune или Configuration Manager Упакованое или внешнее расположение для существующих установщиков Новые приложения должны использовать MSIX. Существующие приложения с собственным установщиком могут использовать упаковку с внешним расположением. Подписание кода: использовать самоподписанный сертификат (доверенный через Intune, групповую политику или Configuration Manager) или Подписание артефактов Azure (ранее — Trusted Signing). развертывание упакованных приложений
Прямое скачивание с собственным установщиком Упаковка для внешнего хранения Зарегистрируйте облегченный идентификационный пакет вместе с существующим установщиком. Для подписывания кода: требуется доверенный сертификат ЦС для распространения вне Магазина. Azure Подписывание артефактов (прежнее название — Доверенное подписывание) — это рекомендуемый вариант с более низкой ценой. → Предоставление идентификации пакета

Кроме того, отправьте существующий установщик в Магазин через путь отправки MSI/EXE.
Внутренняя программа или программа разработчика Распаковка Самое простое в создании и развертывании. Windows App SDK работает через NuGet, но некоторые функции не будут доступны.

Подсказка

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

Зависимое от фреймворка и самодостаточное развертывание

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

Подробное сравнение и рекомендации по развертыванию см. в обзоре развертывания Windows App SDK.

Начать работу с MSIX

Если вы создаете классическое приложение Win32 (иногда называется классическим приложением классическое классическое приложение) или приложением .NET , включая Windows Presentation Foundation (WPF) и Windows Forms (WinForms), вы можете упаковывать и развертывать приложение с помощью MSIX.

Переход на MSIX из устаревших установщиков

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

Текущий установщик Рекомендуемый путь миграции Требуется исходный код?
MSI (установщик Windows) Используйте средство упаковки MSIX для преобразования MSI непосредственно в MSIX. Обрабатывает большинство шаблонов MSI, включая пользовательские действия. Нет
ClickOnce (.NET) Пересоберите из исходного кода с помощью проекта упаковки MSIX в Visual Studio. Автоматическое обновление ClickOnce можно заменить обновлениями Магазина или установщиком приложений. Да
InstallShield / Advanced Installer Используйте средство упаковки MSIX для записи установки на чистую виртуальную машину. Сложные пользовательские действия могут потребовать исправления вручную в редакторе пакетов. Нет
Inno Setup / NSIS Используйте процесс захвата с использованием виртуальной машины в MSIX Packaging Tool. Запустите установщик EXE в чистой среде средства. Нет
App-V (виртуальные пакеты) Преобразуйте напрямую с помощью MSIX Packaging Tool — он поддерживает пакеты App-V 5.x в качестве входных данных. Нет
MSIX с необходимыми изменениями Используйте платформу поддержки пакетов для применения исправлений среды выполнения (перенаправления файлов или реестра) без изменения кода приложения. Нет

Подсказка

Для приложений, использующих сложные установщики с драйверами ядра, службы, работающие от имени SYSTEM, или общесистемную регистрацию COM, которую MSIX не поддерживает, используйте MSIX с внешним расположением (пакет с внешним расположением). Это дает вам идентификатор пакета для функций Windows, при этом для компонентов, которым требуются повышенные привилегии, используется традиционный установщик. См. раздел Предоставление идентификации пакета через упаковку с внешним местонахождением.

Основные рекомендации

  • Проверка на чистой виртуальной машине — средство упаковки MSIX записывает все изменения во время установки. Запустите его на чистом Windows образе, чтобы избежать записи несвязанных изменений системы.
  • Package Support Framework — если у преобразованного приложения возникают проблемы во время выполнения (например, из-за предположений о путях к файлам или записи в реестр HKLM), Package Support Framework может устранить их без изменения исходного кода.
  • Одновременно с прежним установщиком — вы можете развернуть версию MSIX одновременно с прежним установщиком в переходный период. Запланируйте явные параметры и миграцию данных (например, импорт при первом запуске), так как идентификаторы пакетов и расположения хранилища отличаются между установками MSIX и MSI/EXE.

Другие технологии установки