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

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

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

• Ставить на одного пользователя или на всю машину
• Отдать обновления платформе распространения или взять их на себя
• Есть ли интеграция с ОС: службы / драйверы / расширения оболочки / регистрация COM
• Нужно ли выдерживать изолированную сеть, офлайн, раздачу с USB
• Нужен ли package identity — или приложение должно работать unrestricted как обычный Win32

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

flowchart TB
    accTitle: Две оси, по которым выбирают способ распространения
    accDescr: Способ распространения выбирают не по предпочтению формата установщика — что новее или что проще, — а по двум осям: насколько глубоко встраиваться в ОС и кто несёт ответственность за обновления.
    a0["«Что новее / что проще»"] -.-> a1["По этой оси не решают"]
    a2["Насколько глубоко встраиваться в ОС"] --> a4["Так выбирается способ"]
    a3["Кто отвечает за обновления"] --> a4

Рис. 1: Способ выбирают не по вкусу, а по глубине интеграции с ОС и по ответственности за обновления.

Статья написана для разработчиков настольных Windows-приложений, которые сейчас выбирают способ распространения или пересматривают текущий, и для сотрудников ИТ, которые затем примут эту эксплуатацию на себя. Конкретный язык или фреймворк не предполагаются. В этой области много терминов ходят по-английски — они собраны в 1.1. Содержимое таблицы в начале статьи кратко разобрано в 1.2.

1. Сначала вывод

Грубо, но так, чтобы этим можно было пользоваться.

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

Если совсем сжато, получается так.

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

flowchart TB
    accTitle: Грубое сведение пяти способов
    accDescr: Глубокая регистрация в ОС ведёт к MSI; package identity и modern packaging — к MSIX; простая раздача per-user со встроенным обновлением — к ClickOnce; скопировать и запустить — к xcopy; готовность самим держать инфраструктуру обновлений — к собственному updater.
    b1{"Глубокая регистрация в ОС?"} -->|"да"| b2["Склоняться к MSI"]
    b1 -->|"нет"| b3{"Нужен package identity?"}
    b3 -->|"да"| b4["MSIX"]
    b3 -->|"нет"| b5{"Простая раздача per-user + автообновление?"}
    b5 -->|"да"| b6["ClickOnce"]
    b5 -->|"Главное — скопировать и запустить"| b7["xcopy"]
    b7 -.-> b8["Если готовы сами держать инфраструктуру обновлений — свой updater"]

Рис. 2: Если застряли, разводите по глубине регистрации, identity и простоте раздачи.

1.1 Термины, которые встречаются в тексте

Вокруг распространения много терминов ходят по-английски, поэтому сначала список.

1.2 Что лежит в таблице в начале статьи

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

Лист Planner состоит из трёх блоков.

1. Лист ввода: заполняете 7 пунктов — и можно записать первого кандидата и причину
   • Область распространения … per-user / per-machine / оба / ещё не решено
   • Элементы интеграции с ОС … нет / служба / драйвер / shell extension / регистрация COM / несколько
   • package identity … нужен / не нужен / нельзя решить
   • Требование ставить от обычного пользователя … обязательно / не нужно / зависит от условий
   • Частота обновлений … вручную или редко / ежемесячно / еженедельно / чаще
   • Целевая среда … изолированная сеть / офлайн / управляемая свежая Windows / смесь со старыми поколениями Windows / USB и площадка
   • Тип приложения … внутренний .NET desktop / коммерческий продукт / утилита / смесь
2. Как различить кандидатов: у каждого из пяти способов — «когда смотреть в первую очередь» и «когда его легко отсечь»
3. Ход решения: в каком порядке смотреть пункты и к какому способу это обычно подталкивает

Лист Reference держит как есть таблицу решений из главы 3 и сравнительную таблицу из главы 4.

То есть это главы 3, 4 и 7 статьи в виде, который можно заполнять по проекту. Если после чтения вывод уже ясен, скачивать не нужно. Имеет смысл, когда сравниваете несколько проектов или хотите оставить внутри компании обоснование решения.

flowchart TB
    accTitle: Как пользоваться таблицей
    accDescr: На листе Planner заполняют 7 пунктов, сужают кандидатов и ход решения, записывают первого кандидата и причину; лист Reference — это таблицы из глав 3 и 4.
    c1["Заполнить 7 пунктов листа ввода"] --> c2["Сузить по различиям кандидатов"]
    c2 --> c3["Подтолкнуть к способу ходом решения"]
    c3 --> c4["Записать первого кандидата и причину"]
    c4 -.-> c5["Reference — таблицы глав 3 и 4"]

Рис. 3: Таблица превращает решение из статьи в запись по конкретному проекту.

Карта знаний этой статьи

Способ распространения Windows-приложения выбирают не по вкусу к форме установщика, а по двум осям: насколько глубока интеграция с ОС и кто несёт ответственность за обновления. MSI подходит для внедрения, которое глубоко трогает ОС — Windows-служба, регистрация COM, драйвер или расширение оболочки, — но package identity не имеет; MSIX реализует package identity и даёт чистоту clean install и обновления, но в основном не подходит для драйверов и расширений оболочки. ClickOnce позволяет просто распространять и автоматически обновлять .NET-приложение per-user, но не подходит для продукта, в который входит Windows-служба; распространение xcopy сильно простотой «положил и работает», зато не сочетается с package identity и службами. Собственный updater — выбор, при котором проверку подписи и управление сертификатом подписи кода берут на себя, а взамен получают свободу обновлений и способность к распространению в изолированной сети.

flowchart LR
    accTitle: Карта знаний способов распространения Windows-приложений
    accDescr: Схема, которая показывает, как MSI, MSIX, ClickOnce, xcopy и собственный updater различают по двум осям: глубине интеграции с ОС и тому, кто несёт ответственность за обновления.
    msi["MSI (Windows Installer)"]
    msix["MSIX"]
    clickonce["ClickOnce"]
    windows_service["служба Windows"]
    driver_package["пакет драйвера"]
    shell_extension["расширение оболочки (Explorer)"]
    com["COM (Component Object Model)"]
    closed_network["замкнутая сеть"]
    package_identity["package identity"]
    code_signing_cert["сертификат подписи кода"]
    dotnet[".NET (начиная с Core)"]
    xcopy_deployment["распространение xcopy"]
    custom_updater["собственный updater"]
    msi -->|"рекомендуется для"| windows_service
    msi -->|"рекомендуется для"| driver_package
    msi -->|"рекомендуется для"| shell_extension
    msi -.->|"использует"| com
    msi -->|"рекомендуется для"| closed_network
    msix -->|"реализует"| package_identity
    msix -->|"не рекомендуется"| driver_package
    msix -.->|"не рекомендуется"| shell_extension
    msix -.->|"рекомендуется для"| closed_network
    msix -->|"требует"| code_signing_cert
    clickonce -.->|"требует"| dotnet
    clickonce -.->|"рекомендуется для"| closed_network
    clickonce -->|"не рекомендуется"| windows_service
    xcopy_deployment -->|"не рекомендуется"| windows_service
    xcopy_deployment -->|"рекомендуется для"| closed_network
    custom_updater -.->|"требует"| code_signing_cert
    custom_updater -.->|"рекомендуется для"| closed_network

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 17, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Эти пять — не одна категория

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

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

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

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

flowchart TB
    APP["Windows-приложение, которое нужно распространить"] --> Q1["Сначала: как ставить<br/>слой первичной установки"]
    APP --> Q2["Затем: кто отвечает за обновления<br/>слой последующих обновлений"]

    Q1 --> MSI["MSI"]
    Q1 --> MSIX["MSIX"]
    Q1 --> CO["ClickOnce"]
    Q1 --> XC["xcopy"]

    Q2 --> AI["MSIX App Installer"]
    Q2 --> COU["Встроенное обновление ClickOnce"]
    Q2 --> MAN["Ручная замена"]
    Q2 --> OWN["Свой updater"]

    MSIX -.-> AI
    CO -.-> COU
    MSI -.-> MAN
    XC -.-> MAN
    MSI -.-> OWN
    XC -.-> OWN

Рис. 4: Двухслойная модель. Пунктир — средство обновления, которое стыкуется естественно.

У ClickOnce и MSIX, как только выбран верхний слой, нижний почти определяется сам. У MSI и xcopy нижний слой нужно решать отдельно. Вопрос «как обновлять» чаще всего повисает в воздухе именно когда выбирают эти два.

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

flowchart TB
    accTitle: Обновление повисает у MSI и xcopy
    accDescr: У ClickOnce и MSIX выбор способа установки почти задаёт и средство обновления; у MSI и xcopy слой последующих обновлений нужно решать отдельно, а свой updater добавляют, когда этих требований не хватает.
    d1["Выбирают ClickOnce / MSIX"] --> d2["Средство обновления почти задано"]
    d3["Выбирают MSI / xcopy"] --> d4["Вопрос обновления повисает"]
    d4 --> d5["Слой последующих обновлений решают отдельно"]
    d5 -.-> d6["Если не хватает — добавляют свой updater"]

Рис. 5: Собственный updater — не первый вариант, а дополнение, которое закрывает дыру в слое обновлений.

3. Таблица решений на одном экране

Сначала — самая удобная таблица решений.

Главное в этой таблице: из того, что «обновления всё равно есть», к своему updater не перескакивают.

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

Смотреть здесь нужно не на то, что сильнее всех, а на то, где меньше всего трения.

5. Каким задачам какой способ подходит

5.1 MSI

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

Особенно хорошо он ложится на такие задачи.

• бизнес-приложение на всех пользователей
• приложение со службой Windows
• приложение с регистрацией COM, file association, настройками machine-wide
• продукт, у которого уже есть эксплуатация установщика

Сильная сторона MSI — легко выразить в терминах Windows, как приложение попало в ОС.

Слабые стороны тоже ясны.

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

flowchart TB
    accTitle: Сильная сторона MSI и цена
    accDescr: MSI удобно выражает в терминах Windows, как приложение попало в ОС, но authoring сложен, чем больше custom action тем хрупче, а при частых обновлениях UX обновления становится тяжёлым.
    e1["MSI"] --> e2["Как ставят в ОС — в терминах Windows"]
    e2 --> e3["Есть install / uninstall / repair"]
    e1 -.-> e4["Authoring сложнее, чем кажется"]
    e4 -.-> e5["Чем больше custom action, тем хрупче"]

Рис. 6: MSI даёт выразительность интеграции с ОС ценой сложности authoring.

5.2 MSIX

MSIX — выбор, когда нужны modern packaging и clean update / uninstall. Его ценность сильно растёт, если нужны функции Windows, завязанные на package identity.

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

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

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

Но подходит не всё. Эти четыре пункта лучше проверить в самом начале.

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

У этих четырёх разные источники проверки. Не останавливайтесь на «кажется, MSIX не пойдёт»: заранее решите, каким документом закрываете вопрос.

Ссылки — в главе 9. При решении смотрите не «поддерживается или нет», а «с какой версии и какой декларацией поддерживается». Если не зафиксировать это вместе с версией ОС, потом вылезает «на проверочной машине встало, на старой Windows в поле — нет».

flowchart TB
    accTitle: Ограничения MSIX закрывают до источника проверки
    accDescr: Четыре спорных места MSIX вроде расширения оболочки и драйвера сидят в разных документах; не останавливаются на «кажется, не пойдёт», а смотрят, с какой версии и какой декларацией это поддерживается, чтобы не получить «на проверочной машине да, в поле нет».
    f1["Четыре спорных места MSIX"] --> f2["Не останавливаться на «кажется, не пойдёт»"]
    f2 --> f3["Решить, каким документом закрывать"]
    f3 --> f4["Дойти до версии и декларации"]
    f4 -.-> f5["Не получить «проверка да, поле нет»"]

Рис. 7: Ограничения MSIX закрывают только вместе с версией ОС и способом декларации.

5.3 ClickOnce

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

Подходит для таких случаев.

• внутреннее бизнес-приложение
• нужно ставить от обычного пользователя
• раздачи на пользователя достаточно
• UX обновления глубоко строить не хочется

Наоборот, не стоит рассчитывать, что он сыграет роль продукта, который глубоко затрагивает ОС, или роль установщика, который собирает несколько prerequisite.

5.4 xcopy

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

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

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

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

flowchart TB
    accTitle: xcopy — это deploy, не install
    accDescr: У xcopy нет регистрации в реестре, восстановления и package identity, зато если достаточно положить файлы, он работает как есть; обновляют заменой папки, возвращаются подстановкой предыдущей версии — способ сломаться понятен.
    g1["Кладут папку целиком"] --> g2["Работает как есть"]
    g2 --> g3["Обновление — замена папки"]
    g3 --> g4["Откат — подставить предыдущую версию"]
    g1 -.-> g5["Нет регистрации, восстановления, identity"]

Рис. 8: Ценность xcopy в том, что установка, обновление и откат просты.

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

• Start menu / ARP / repair
• file association / service / shell extension / driver
• встроенное обновление

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

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

Смотреть имеет смысл, когда есть такие требования.

• высокая частота обновлений
• нужны каналы вроде stable / beta / preview
• нужно управлять поэтапной выдачей и долей rollout
• нужна тонкая настройка фоновой загрузки, уведомлений и окна обслуживания
• телеметрию обновлений и crash recovery хотите видеть сами

Сильная сторона велика, и плата тоже.

• проверка подписи
• манифест доставки
• повторные попытки / resume
• proxy / firewall / изолированные сети
• rollback
• восстановление после сломанного обновления
• обновление самого updater

То есть растёт не свобода, а ответственность.

flowchart TB
    accTitle: Свой updater — выбор ответственности
    accDescr: Свой updater даёт каналы, поэтапную выдачу и телеметрию, а взамен вы сами проектируете и эксплуатируете проверку подписи, манифест доставки, rollback, восстановление после сломанного обновления и обновление самого updater.
    h1["Получаете: каналы, поэтапная выдача, телеметрия"] --> h3["Свой updater"]
    h2["Платите: проверка подписи, rollback, восстановление"] --> h3
    h3 --> h4["Растёт не свобода, а ответственность"]
    h2 -.-> h5["Обновление самого updater тоже ваша работа"]

Рис. 9: Со своим updater растёт не свобода, а ответственность за эксплуатацию инфраструктуры обновлений.

5.6 Когда способ выбран, что смотреть дальше

Даже после «идём в MSI» можно остановиться, если непонятно, что искать. Ниже типичные отправные точки. Это не «пользуйтесь вот этим», а имена, которые стоит знать, если способ уже выбран.

Здесь важно: выбор инструмента и выбор способа — разные вещи. Inno Setup удобен, но на выходе не MSI, поэтому он не ложится на эксплуатацию, которая предполагает Windows Installer: например, раздачу ПО через групповую политику или восстановление через msiexec. Если в 5.1 MSI выбрали именно поэтому, инструмент тоже должен этому соответствовать.

flowchart TB
    accTitle: Выбор инструмента и выбор способа — не одно и то же
    accDescr: Inno Setup удобен, но MSI не делает, поэтому не ложится на раздачу через GPO и восстановление msiexec; инструмент подбирают под причину, по которой выбрали способ.
    i1["Сначала способ"] --> i2["Потом инструмент"]
    i2 -.-> i3["Inno Setup не делает MSI"]
    i3 -.-> i4["Не ложится на раздачу GPO и msiexec"]
    i4 -.-> i5["Инструмент подгоняют под причину выбора способа"]

Рис. 10: Удобный инструмент не обязан вписываться в модель выбранного способа.

6. Где легко запутаться

6.1 Нужен ли package identity

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

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

• unrestricted-доступ к файловой системе
• unrestricted-доступ к реестру
• свобода elevation / модели процессов
• оставить допущения старого Win32 как есть

естественнее выбрать способ ближе к unpackaged.

flowchart TB
    accTitle: Разводят по необходимости package identity
    accDescr: Если нужна функция Windows, которая предполагает package identity, ценность MSIX резко растёт; если хотят unrestricted-доступ к файлам и реестру или оставить допущения старого Win32, естественнее способ ближе к unpackaged.
    j1{"Нужна функция, которая предполагает package identity?"} -->|"да"| j2["Ценность MSIX резко растёт"]
    j1 -->|"Хотите работать unrestricted"| j3["Естественнее способ ближе к unpackaged"]

Рис. 11: Нужен ли identity — водораздел между packaged и unpackaged.

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

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

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

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

6.3 per-user или per-machine

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

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

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

flowchart TB
    accTitle: per-user и per-machine не путают
    accDescr: К per-user ближе ClickOnce, xcopy и часть MSIX; к per-machine — MSI и при подходящих условиях MSIX; установка без прав и общее для всех место — разные вещи.
    k1["Склоняться к per-user"] --> k2["ClickOnce / xcopy / часть MSIX"]
    k3["Склоняться к per-machine"] --> k4["MSI / MSIX, если условия сходятся"]
    k1 -.-> k5["Установка без прав и общее место для всех — разные вещи"]

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

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

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

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

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

flowchart TB
    accTitle: Ступени частоты обновлений
    accDescr: От квартала до месяца хватает MSI; от месяца до недели легче MSIX или ClickOnce; от недели до дня появляется причина смотреть свой updater; если хватает вручную, хватает и xcopy.
    m1["Квартал — месяц: хватает MSI"] --> m2["Месяц — неделя: легче MSIX / ClickOnce"]
    m2 --> m3["Неделя — день: причина смотреть свой updater"]
    m1 -.-> m4["Если хватает вручную — хватает xcopy"]

Рис. 13: Чем чаще обновления, тем выше ценность встроенного обновления или своей инфраструктуры.

6.5 Изолированная и офлайн-раздача

В изолированной сети простота часто побеждает аккуратное auto-update.

• xcopy силён
• MSI тоже силён
• ClickOnce тоже работает с file share или со сменного носителя
• MSIX тоже можно крутить — зависит от того, как пользоваться App Installer

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

flowchart TB
    accTitle: В изолированной сети побеждает простота
    accDescr: В изолированной сети простота часто побеждает аккуратное auto-update; если обновляют часто, пока не решите, кто куда кладёт новую версию и как оставляют старую, одного выбора способа для эксплуатации не хватает.
    n1["Изолированная / офлайн-среда"] --> n2["Простота важнее аккуратного auto-update"]
    n2 --> n3["Сильны xcopy и MSI"]
    n2 -.-> n4["Решить, кто и куда кладёт новую версию"]
    n4 -.-> n5["Решить, как оставляют старую"]

Рис. 14: В изолированной сети раньше способа решают, как кладут новую и старую версии.

7. Шесть вопросов, к которым стоит вернуться в конце

1. Приложению достаточно current user или его нужно ставить machine-wide
2. Есть ли service / driver / shell extension / регистрация COM
3. Используются ли функции Windows, которым нужен package identity
4. Хотите ли ставить только от обычного пользователя
5. Частота обновлений — ежемесячная, еженедельная или выше
6. Целевая среда изолирована, версии ОС однородны

Достаточно ответить на эти шесть вопросов — и итоговый выбор обычно виден.

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

flowchart TB
    accTitle: Куда приводят шесть вопросов
    accDescr: Если есть интеграция с ОС вроде служб, сначала MSI; если нужен package identity, в первую очередь MSIX; .NET desktop per-user от обычного пользователя тянет к ClickOnce; эксплуатация «скопировал и запустил» — к xcopy; если хотят держать UX обновления, в сравнение берут и свой updater.
    p1{"Есть интеграция с ОС (службы и т.п.)?"} -->|"да"| p2["Сначала думать со стороны MSI"]
    p1 -->|"нет"| p3{"Нужен package identity?"}
    p3 -->|"да"| p4["В первую очередь смотреть MSIX"]
    p3 -->|"нет"| p5{"per-user и установка от обычного пользователя?"}
    p5 -->|".NET desktop"| p6["Сильный кандидат ClickOnce"]
    p5 -->|"Если хватает скопировать и запустить"| p7["Сильный кандидат xcopy"]
    p6 -.-> p8["Если хотите держать UX обновления, сравните и свой updater"]

Рис. 15: Если идти по ответам на шесть вопросов в этом порядке, итоговый выбор обычно виден.

8. Итог

Способ распространения Windows-приложения довольно хорошо сходится к одной фразе.

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

Отсюда грубое практическое решение такое.

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

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

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

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

flowchart TB
    accTitle: Три вещи, которые фиксируют раньше
    accDescr: Если застряли, даже если сначала зафиксировать только per-user или per-machine, что регистрируется в ОС и какова частота обновлений, разговор про способ распространения заметно продвигается.
    q1["per-user или per-machine"] --> q4["Фиксируют раньше"]
    q2["Что регистрируется в ОС"] --> q4
    q3["Какова частота обновлений"] --> q4
    q4 --> q5["Разговор заметно продвигается"]

Рис. 16: Если застряли на способе, сначала фиксируют хотя бы эти три пункта.

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 и расширения оболочки — то есть на сценарии, которые глубоко затрагивают ОС, — и позволяет выразить install / uninstall / repair в терминах Windows. MSIX — modern packaging под Windows 10/11; его сильные стороны — clean install / clean uninstall, частые обновления и package identity. Зато MSIX плохо подходит для драйверов; in-process-расширения оболочки поддерживаются условно начиная с Windows 11 21H2; и он не рассчитан на unrestricted-сценарии старого Win32. Если регистрация в ОС глубокая — отправная точка MSI; если нужны package identity и аккуратные обновления — MSIX.

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

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

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

Можно, и в подходящих сценариях это очень сильный вариант. Он хорошо работает, когда внутреннее .NET desktop-приложение нужно быстро раздавать per-user, с правами обычного пользователя, и крутить обновления встроенной моделью. Не стоит ждать от него роли продукта, который глубоко затрагивает ОС — службы Windows, драйверы, расширения оболочки, — или роли установщика, который собирает несколько prerequisite. По частоте обновлений: от ежемесячных до еженедельных ClickOnce и MSIX крутятся довольно спокойно.

Когда стоит рассматривать свой updater?

Собственный updater выбирают не первым. Его добавляют, когда у существующего способа распространения не хватает требований к обновлению. Имеет смысл смотреть, если обновления частые, нужны каналы вроде stable / beta / preview, хочется управлять поэтапной выдачей и долей rollout, или сами хотите видеть телеметрию обновлений и crash recovery. Но тогда на вас ложатся проверка подписи, манифест доставки, повторные попытки, rollback, восстановление после сломанного обновления и обновление самого updater. Это выбор, который увеличивает ответственность, а не свободу.

Об авторе

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

Го Комура

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

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