Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/собственный updater

Скачать Excel-таблицу для принятия решения (с японским и английским листами)

При выборе способа распространения Windows-приложения легко начать разговор с вопросов «что новее» или «что проще». Но на практике по-настоящему важны другие критерии.

• Устанавливать на уровне пользователя (per-user) или на уровне всей машины (per-machine)?
• Доверить обновления платформе распространения или взять ответственность на себя?
• Есть ли интеграция с ОС — службы, драйверы, расширения оболочки, регистрация COM?
• Должен ли способ выдерживать изолированную сеть, офлайн-среду, распространение через USB?
• Нужен ли package identity, или приложение должно работать как обычный, неограниченный (unrestricted) Win32?

Выбор способа распространения — это не вопрос вкуса в формате установщика, а выбор того, насколько глубоко приложение вмешивается в ОС и кто несёт ответственность за обновления.

1. Сначала — главный вывод

Если сформулировать довольно грубо, но удобно для практики, получится так.

• Если приложение устанавливается на всю машину, регистрирует службы или COM, либо требует установки внешних предпосылок, отправной точкой стоит взять MSI
• Если можно рассчитывать на Windows 10/11 и нужны чистая установка/удаление, частые обновления и package identity, сильный кандидат — MSIX
• Если нужно просто распространить внутреннее .NET desktop-приложение по пользователям и настроить автообновление, ClickOnce и сегодня остаётся весьма сильным вариантом
• Если приоритет — инструменты, работающие сразу после копирования, изолированные сети, распространение через USB и работа без прав администратора, самый прямолинейный вариант — xcopy
• Если вы хотите полностью контролировать UX обновления, каналы, поэтапное развёртывание, телеметрию и стратегию восстановления, это путь собственного updater
• Если требуется драйвер, с самого начала не стоит строить решение вокруг MSIX
• Если требуется in-process-расширение оболочки Проводника, сначала стоит проверить, что именно поддерживает MSIX, и условия по версии ОС

Если обобщить грубо, получается так.

1. Плотная регистрация в ОС → склоняться к MSI
2. Нужны package identity и modern packaging → MSIX
3. Нужны простое распространение per-user и встроенные обновления → ClickOnce
4. Распространение простым копированием — приоритет №1 → xcopy
5. Готовность самостоятельно проектировать и эксплуатировать инфраструктуру обновлений → собственный updater

2. Эти пять вариантов не на одном игровом поле

Этот момент действительно важен.

MSI / MSIX / ClickOnce / xcopy — в первую очередь о том, как установить. Собственный updater, напротив, — в первую очередь о том, как взять на себя ответственность за обновления.

То есть на практике удобнее рассматривать это в два слоя.

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

3. Таблица решений на одной странице

Начнём с самой удобной для использования таблицы решений.

Самое важное в этой таблице — не переходить к собственному updater только потому, что «обновления всё равно нужны».

4. Сравнение по критериям

В этой таблице важно смотреть не на то, что сильнее всего, а на то, что создаёт меньше всего трения.

5. Для каких проектов подходит каждый вариант

5.1. MSI

MSI — это точка отсчёта, когда нужно аккуратно устанавливать, удалять и восстанавливать традиционное desktop-приложение Windows.

Особенно хорошо он подходит для таких проектов.

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

Сильная сторона MSI — то, что он позволяет выразить «как приложение было установлено в ОС» в привычной для Windows логике.

Но и слабые стороны выражены достаточно чётко.

• разработка (authoring) незаметно сложна;
• небрежное проектирование upgrade/patch впоследствии причиняет боль;
• чем больше custom action, тем менее устойчива конструкция;
• для продуктов с высокой частотой обновлений UX обновления становится тяжеловесным.

5.2. MSIX

MSIX — это выбор, когда нужны modern packaging и чистое обновление/удаление. Он приобретает особый смысл, если нужны функции Windows, зависящие от package identity.

Хорошо подходит примерно для такого.

• desktop-приложений, для которых можно рассчитывать на Windows 10/11;
• бизнес-приложений с относительно высокой частотой обновлений;
• приложений, которым нужны функции Windows, работающие благодаря package identity;
• проектов, ориентированных на Intune или App Installer.

Сильная сторона MSIX — аккуратность обновления и удаления.

Но подходит он не для всего. Особенно стоит заранее проверить следующие четыре момента.

• in-process-расширения оболочки (MSIX в Windows 11 21H2 и новее может регистрировать legacy-обработчики контекстного меню и подобное, но нужно проверить декларации манифеста и целевую ОС);
• драйверы;
• сценарии со старыми, неограниченными (unrestricted) допущениями Win32;
• конфигурации, где package identity нежелателен.

5.3. ClickOnce

ClickOnce и сегодня остаётся весьма сильным вариантом, когда нужно быстро распространять внутреннее .NET desktop-приложение по пользователям, включая обновления.

Хорошо подходит для таких сценариев.

• внутренние бизнес-приложения;
• нужна установка от имени обычного пользователя;
• распространения по пользователям (per-user) достаточно;
• нет желания глубоко прорабатывать UX обновления.

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

5.4. xcopy

xcopy — это не установка (install), а развёртывание (deploy). Нет ни регистрации в реестре, ни функции восстановления, ни package identity. Зато если достаточно просто разместить файлы, это один из самых простых вариантов в принципе.

Его сильная сторона раскрывается для таких инструментов.

• диагностические инструменты;
• инструменты настройки оборудования;
• инструменты сбора логов;
• утилиты, передаваемые на объект через USB;
• случаи, когда нужно, чтобы несколько версий сосуществовали параллельно (side-by-side).

Сильная сторона xcopy — понятность режимов сбоя. Заменить всю папку целиком, а если нужно откатиться — вернуться к предыдущей версии: такой режим эксплуатации организовать легко.

Но, разумеется, есть и слабые стороны.

• меню «Пуск» / список программ и компонентов (ARP) / восстановление;
• файловые ассоциации / службы / расширения оболочки / драйверы;
• встроенные обновления.

5.5. Собственный updater

Собственный updater — это скорее выбор ответственности, чем выбор свободы.

Рассматривать его стоит при наличии таких требований.

• высокая частота обновлений;
• нужны каналы вроде stable/beta/preview;
• нужен контроль поэтапного развёртывания и доли аудитории (rollout);
• нужен тонкий контроль над фоновой загрузкой, уведомлениями и окнами обслуживания;
• нужны собственные телеметрия обновлений и восстановление после сбоев.

Преимущества велики, но и цена, которую приходится платить, тоже.

• проверка подписи;
• манифест доставки;
• повторные попытки / возобновление;
• поддержка прокси / межсетевого экрана / изолированных сетей;
• откат (rollback);
• восстановление после сломанного обновления;
• обновление самого updater.

Иначе говоря, растёт не свобода, а ответственность.

6. Спорные моменты, вызывающие сомнения

6.1. Нужен ли package identity

Если нужна функция Windows, предполагающая package identity, ценность MSIX резко возрастает.

И наоборот, если нужны:

• неограниченный доступ к файловой системе;
• неограниченный доступ к реестру;
• свобода в повышении привилегий и модели процессов;
• сохранение старых допущений Win32 без изменений,

то более естественным выбором становятся способы, близкие к unpackaged.

6.2. Есть ли службы / драйверы / расширения оболочки

Эти три фактора сразу резко утяжеляют способ распространения.

• драйвер: плохо сочетается с MSIX;
• in-process-расширение оболочки: плохо сочетается с MSIX;
• служба Windows: естественна для MSI, для MSIX сравнима лишь условно.

Чем глубже элементы связаны с ОС, тем сильнее главной темой становится не «насколько простым выглядит распространение», а «можно ли корректно установить, обновить и удалить приложение».

6.3. per-user или per-machine

Если оставить этот вопрос размытым, конфликт впоследствии практически гарантирован.

• склоняться к per-user
  • ClickOnce
  • xcopy
  • часть сценариев MSIX
• склоняться к per-machine
  • MSI
  • MSIX при подходящих условиях

«Хотим устанавливать без прав администратора» и «хотим, чтобы все пользователи работали из одного и того же места» — не одно и то же.

6.4. Частота обновлений и ответственность за эксплуатацию

Если смотреть через призму частоты обновлений, картина примерно такая.

• обновления раз в квартал — раз в месяц: MSI справляется вполне достаточно;
• обновления раз в месяц — раз в неделю: MSIX / ClickOnce заметно удобнее;
• обновления раз в неделю — ежедневно: появляются причины рассмотреть собственный updater;
• обновления можно делать вручную либо их контролирует сторона, выполняющая развёртывание: достаточно xcopy.

Способ распространения — это одновременно и выбор технологии, и проектирование эксплуатации.

6.5. Изолированное и офлайн-распространение

В изолированных сетях простота нередко побеждает изящное автообновление.

• xcopy — сильный вариант;
• MSI — тоже сильный вариант;
• ClickOnce тоже можно использовать через сетевую папку или сменный носитель;
• MSIX тоже может работать, в зависимости от того, как используется App Installer.

Однако если в изолированной сети обновления происходят часто, эксплуатация легко разваливается, если заранее не решить, «кто, куда кладёт новую версию и как сохраняется предыдущая» — одного лишь выбора способа недостаточно.

7. Шесть вопросов, к которым стоит вернуться, если решение не даётся

1. Достаточно ли, чтобы приложение работало только для текущего пользователя, или его нужно устанавливать на всю машину?
2. Есть ли служба / драйвер / расширение оболочки / регистрация COM?
3. Будут ли использоваться функции Windows, требующие package identity?
4. Нужна ли установка исключительно от имени обычного пользователя?
5. Какова частота обновлений — ежемесячная, еженедельная или ещё выше?
6. Целевая среда изолирована? Единообразны ли версии ОС?

Достаточно ответить на эти шесть вопросов, чтобы примерно увидеть, куда двигаться.

• Ответ «да» на вопрос 2 → начинайте рассуждение со стороны MSI
• Ответ «да» на вопрос 3 → в первую очередь рассматривайте MSIX
• Ответ на вопрос 1 — «текущий пользователь», на вопрос 4 — «да», и это .NET desktop-приложение → сильный кандидат ClickOnce
• Ответ на вопрос 4 — «да», на вопрос 2 — «нет», и достаточно эксплуатации простым копированием → сильный кандидат xcopy
• Ответ на вопрос 5 — высокая частота, и UX обновления хотят контролировать как часть ценности продукта → добавьте собственный updater в список сравнения

8. Итог

Выбор способа распространения Windows-приложения во многом сводится к одной формулировке:

Как обеспечить первичную установку и кто несёт ответственность за проведение последующих обновлений — решаются раздельно.

Помимо этого, грубые практические выводы такие.

• MSI: традиционные desktop-приложения, глубоко интегрированные с ОС
• MSIX: приложения, которым нужны package identity и modern packaging/обновления
• ClickOnce: простое распространение и обновление .NET-бизнес-приложений по пользователям
• xcopy: самодостаточные инструменты, для которых достаточно просто разместить файлы
• Собственный updater: продукты, команда которых готова сама проектировать и эксплуатировать обновления

И самое важное — вот что.

• Если есть драйвер / расширение оболочки / служба, способ распространения определяется не финальным внешним видом, а подходом к интеграции с ОС
• Если нужен package identity, значение MSIX резко возрастает
• Собственный updater — это последний козырь, а не первый вариант выбора
• В изолированных сетях простота нередко побеждает изощрённость

Если решение не даётся, для начала стоит зафиксировать всего три вещи — per-user или per-machine, что регистрируется в ОС и какова частота обновлений — и разговор заметно продвинется вперёд.

9. Источники

• Microsoft Learn, Windows Installer
• Microsoft Learn, What is MSIX?
• Microsoft Learn, Packaging overview for Windows apps
• Microsoft Learn, MSIX features and supported platforms
• Microsoft Learn, Support legacy context menus for packaged apps
• Microsoft Learn, App Installer file overview
• Microsoft Learn, Prepare to package a desktop application
• Microsoft Learn, Know your installer
• Microsoft Learn, Convert an installer that includes services
• Microsoft Learn, ClickOnce deployment and security
• Microsoft Learn, Manage updates for a ClickOnce application
• Microsoft Learn, Choosing a ClickOnce deployment strategy
• Microsoft Learn, ClickOnce cache overview
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

В чём разница между MSI и MSIX?

MSI — это традиционный формат установщика Windows, хорошо сочетающийся с внедрением на уровне всей машины (per-machine), службами Windows, регистрацией COM и другими случаями, требующими глубокого вмешательства в ОС; он позволяет выразить установку, удаление и восстановление в привычной для Windows логике. MSIX — это современная упаковка (modern packaging), рассчитанная на Windows 10/11, сильными сторонами которой являются чистая установка и удаление, частые обновления и package identity. При этом MSIX плохо подходит для драйверов, in-process-расширения оболочки поддерживаются лишь условно начиная с Windows 11 21H2, а также плохо сочетается с неограниченными (unrestricted) сценариями старого Win32. Если требуется глубокая регистрация в ОС — отправная точка MSI; если важны package identity и аккуратность обновлений — MSIX.

Что выбрать — MSIX или ClickOnce?

Если нужно просто распространить внутреннее .NET-бизнес-приложение по пользователям (per-user) и настроить автообновление, ClickOnce и сегодня остаётся весьма сильным выбором: встроенная модель обновлений удобна, установка возможна от имени обычного пользователя, а UX обновления не нужно разрабатывать самостоятельно. С другой стороны, если требуются функции Windows, зависящие от package identity, важна чистота установки и удаления, или нужна интеграция с Intune или App Installer, стоит склоняться к MSIX. Ни один из вариантов не подходит для продуктов, глубоко вмешивающихся в ОС, — если есть службы или драйверы, начинать стоит со стороны MSI.

Можно ли до сих пор использовать ClickOnce? Это не устаревшая технология?

Использовать его можно и сегодня, и там, где он уместен, это весьма сильный вариант. Он эффективен, когда нужно быстро распространять внутреннее desktop-приложение на .NET по пользователям (per-user), с правами обычного пользователя, и настроить обновления через встроенную модель. И наоборот, не стоит ожидать от него роли инструмента, глубоко работающего с ОС — таких как службы Windows, драйверы или расширения оболочки, — или роли установщика, объединяющего несколько внешних предпосылок. С точки зрения частоты обновлений — от ежемесячных до еженедельных — ClickOnce и MSIX справляются вполне комфортно.

Когда стоит рассматривать собственный updater?

Собственный updater — это не первый вариант выбора, а дополнительное решение на случай, когда существующих способов распространения не хватает для покрытия требований к обновлению. Его стоит рассматривать, если частота обновлений высока, нужны каналы вроде stable/beta/preview, требуется контроль поэтапного развёртывания и доли аудитории (rollout), или нужны собственные телеметрия обновлений и восстановление после сбоев. Однако при этом на вас ложится ответственность за проверку подписи, манифест доставки, повторные попытки, откат (rollback), восстановление после сломанного обновления и обновление самого updater — то есть это выбор, увеличивающий не свободу, а ответственность.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.