Что такое ClickOnce — как устроен, как обновляется, где подходит и где нет

Когда речь заходит о раздаче десктопных .NET-приложений для Windows, в тени MSI и MSIX то и дело всплывает ClickOnce.

Но если сразу уехать в одну из двух крайностей:

• старая технология, больше не используем;
• наоборот, выглядит просто, значит на ClickOnce можно всё,

почти наверняка промахнётесь.

ClickOnce — не универсальный установщик, который умеет всё. Зато для внутренних .NET-приложений, которые нужно раздавать обычным пользователям и дёшево крутить обновления, он и сегодня очень сильный вариант.

Ниже — что такое ClickOnce, как он работает, в чём силён и где ломается. Смотрим с практической стороны, с большим числом диаграмм Mermaid. Опора — материалы Microsoft Learn, которые можно проверить по состоянию на апрель 2026 года.

Диаграммы концептуальные. В Markdown-средах с поддержкой Mermaid они рисуются как схемы.

Для кого статья

Пишу для разработчиков, которые выбирают, как распространять десктопные .NET-приложения для Windows (WinForms / WPF), и для сотрудников ИТ, которые будут сопровождать эту раздачу и обновления. Предполагаю, что решение «брать ClickOnce или нет» ещё не принято: сначала критерии, а конкретные шаги публикации — в разделе 6.4.

Термины, которые лучше зафиксировать заранее

В тексте несколько англоязычных терминов. Чтобы не спотыкаться на первом появлении, сводка здесь.

Оглавление

1. Сначала вывод
2. Что такое ClickOnce
3. Из чего состоит ClickOnce
4. От установки до запуска
5. Как устроено обновление
6. Где ClickOnce силён
7. Где подходит
8. Где не подходит
9. Где на практике легко застрять
10. Итог
11. Связанные статьи
12. Источники

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

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

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

Подходит, например, в таких случаях.

• внутренние бизнес-приложения на WinForms / WPF;
• хочется ставить от обычного пользователя;
• per-user распространения достаточно;
• обновление нужно встроенным;
• канала хватает веб-сайта или файлового ресурса.

Наоборот, при таких требованиях безопаснее сразу смотреть другой способ.

• machine-wide install на всех пользователей;
• служба Windows, драйвер, in-process shell extension, серьёзная регистрация COM;
• нужен package identity;
• хочется самим держать каналы обновления, поэтапную доставку, свой UX отката;
• на установщик вешают глубокую интеграцию с ОС.

Коротко: ClickOnce силён в простой раздаче и простом обновлении и слаб, когда проект глубоко встраивается в ОС.

Сначала одна схема

flowchart TD
    A["Хотим раздать Windows-приложение"]
    B{"Есть требование глубокой интеграции с ОС?"}
    C["Смотреть со стороны MSI / MSIX"]
    D{"Это десктопное .NET-приложение для Windows,<br/>и хватает per-user распространения?"}
    E{"Нужно раздавать обычным пользователям?"}
    F{"Хватает встроенного обновления?"}
    G["ClickOnce — сильный кандидат"]
    H["Сравнить также xcopy / собственный updater"]

    A --> B
    B -- да --> C
    B -- нет --> D
    D -- нет --> H
    D -- да --> E
    E -- нет --> H
    E -- да --> F
    F -- да --> G
    F -- нет --> H

2. Что такое ClickOnce

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

Важно не считать ClickOnce просто «ещё одним видом установщика».

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

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

Ядро ClickOnce — не сам setup.exe, а механизм вокруг манифестов: раздача, обновление и управление кэшем.

В актуальном .NET ClickOnce по-прежнему обычный кандидат. В Visual Studio для .NET Core 3.1 и .NET 5+ используется средство публикации (Publish tool); если манифесты правят вручную — dotnet-mage.exe.

Что ClickOnce берёт на себя

flowchart LR
    CO["ClickOnce"]
    V["Какую версию раздавать"]
    U["Откуда брать обновления"]
    S["Хранение в безопасном месте у каждого пользователя"]
    I["Проверка целостности и запуск"]

    CO --> V
    CO --> U
    CO --> S
    CO --> I

3. Из чего состоит ClickOnce

Короткий путь понять устройство — эти четыре элемента.

Ядро — два манифеста.

• Манифест развёртывания отвечает: «какая версия сейчас считается правильной для этого приложения»
• Манифест приложения отвечает: «что внутри этой версии»

То есть проверка обновления начинается с манифеста развёртывания, а что реально качать — решает манифест приложения.

Как связаны четыре элемента

flowchart LR
    Setup["setup.exe<br/>необязательно<br/>проверка / установка предварительных требований"]
    Deploy["Манифест развёртывания (.application)<br/>какую версию раздавать<br/>источник / условия обновления"]
    App["Манифест приложения (*.exe.manifest)<br/>содержимое этой версии<br/>список файлов / хеши / точка входа"]
    Files["Само приложение<br/>exe / dll / config / data"]
    Cache["Кэш ClickOnce<br/>per-user / per-application"]

    Setup --> Deploy
    Deploy --> App
    App --> Files
    Files --> Cache

setup.exe — не главный, а вспомогательный

setup.exe бросается в глаза, но это не центр ClickOnce. Это помощник, который проверяет и ставит предварительные требования.

Если нужен нужный runtime .NET или дополнительные распространяемые компоненты, setup.exe сначала готовит их, и только потом начинается собственно раздача ClickOnce.

4. От установки до запуска

Если упростить процесс ClickOnce до рабочей схемы, получается так.

1. Пользователь открывает setup.exe или .application на веб-странице или в общей папке
2. Если в конфигурации есть setup.exe, проверяются предварительные требования и ставится недостающее
3. ClickOnce читает манифест развёртывания
4. Читается манифест приложения, на который тот указывает
5. Нужные файлы скачиваются и раскладываются в кэш ClickOnce этого пользователя
6. Если включена автономная работа, приложение регистрируется в меню «Пуск» или в списке приложений
7. Дальше приложение запускается уже под управлением ClickOnce

Главное: это не «положить в Program Files, как обычный установщик».

Приложение ClickOnce попадает в безопасную область кэша конкретного пользователя и изолируется по приложению и по пользователю. Это одна из главных черт ClickOnce.

От установки до первого запуска

sequenceDiagram
    participant U as Пользователь
    participant P as setup.exe / .application
    participant D as Манифест развёртывания
    participant A as Манифест приложения
    participant C as Кэш ClickOnce
    participant X as Само приложение

    U->>P: Открывает
    Note over U,P: Если используется setup.exe,<br/>сначала проверка предварительных требований
    P->>D: Получает и читает
    D->>A: Ссылается на нужную версию
    A->>C: Скачивает файлы, проверяет целостность
    C->>X: Размещает и запускает

Только онлайн и с автономной работой

У ClickOnce два основных режима показа.

• Только онлайн: запуск от места публикации. Ощущения «постоянно установленного» приложения мало
• С автономной работой: ставится на машину пользователя, запускается и из меню «Пуск»

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

flowchart LR
    subgraph Online[Только онлайн]
        O1["Запуск от места публикации"]
        O2["Слабое ощущение постоянной установки"]
        O3["Часто предполагает сеть"]
        O1 --> O2 --> O3
    end

    subgraph Offline[С автономной работой]
        F1["Установка в область пользователя"]
        F2["Регистрация в меню Пуск"]
        F3["Запуск локально"]
        F4["Проверка обновлений в заданный момент"]
        F1 --> F2 --> F3 --> F4
    end

5. Как устроено обновление

Самая понятная сила ClickOnce — встроенная модель обновления.

Проверка начинается с манифеста развёртывания

Приложение ClickOnce читает манифест развёртывания и смотрит:

• есть ли новая версия;
• обязательное ли это обновление;
• откуда её брать.

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

Проверку обновлений удобно разложить на три схемы:

• проверить до запуска;
• проверить после запуска;
• сделать в приложении свой UI «проверить обновления».

Но между .NET Framework и .NET 5+ отличаются и API, и UI настроек. Не начинайте реализацию по памяти из старых статей про ClickOnce.

Поток обновления

flowchart TD
    Start["Запуск приложения"]
    Check["Проверка манифеста развёртывания"]
    New{"Есть новая версия?"}
    Run["Запуск как есть"]
    Get["Получение манифеста приложения новой версии"]
    Compare["Сравнение подписей / хешей файлов"]
    Download["Скачивание изменившегося"]
    Switch["Сборка новой версии и переключение"]
    Restart["При необходимости запуск новой версии после перезапуска"]

    Start --> Check --> New
    New -- нет --> Run
    New -- да --> Get --> Compare --> Download --> Switch --> Restart

Ещё одна рабочая предпосылка: если сети нет, проверка обновлений не делается, приложение просто запускается. Это снимает лишнюю путаницу на площадке.

Версии хранятся раздельно

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

В кэше ClickOnce текущая и предыдущая версии лежат раздельно. Поэтому окружение меньше засоряется и версии реже сталкиваются.

flowchart TB
    subgraph UA[Кэш ClickOnce пользователя A]
        APrev["Предыдущая версия"]
        ACur["Текущая версия"]
        AData["Настройки / данные"]
    end

    subgraph UB[Кэш ClickOnce пользователя B]
        BPrev["Предыдущая версия"]
        BCur["Текущая версия"]
        BData["Настройки / данные"]
    end

    APrev --> ACur
    AData --> ACur
    BPrev --> BCur
    BData --> BCur

Здесь важны два момента.

• Данные разных пользователей почти не смешиваются
• Версии почти не конфликтуют друг с другом

Так называемый DLL Hell обходится легче именно из-за этой структуры.

6. Где ClickOnce силён

Плюс не сводится к «легко раздать». На практике работают примерно такие вещи.

6.1 Легко раздавать обычным пользователям

ClickOnce хорошо ложится на per-user распространение: ставить без прав администратора проще.

Во внутренних бизнес-приложениях типична картина:

• пользователи — обычные пользователи;
• не хочется каждый раз писать в ИТ заявку на установку;
• но обновления останавливать нельзя.

В этих условиях ClickOnce силён. Исходная предпосылка — «в область каждого пользователя, безопасно, вместе с обновлением» — сразу совпадает с задачей.

6.2 Не нужно писать обновление самим

Автообновление с нуля на вид простое, по объёму — нет.

• обнаружение новой версии;
• загрузка;
• проверка целостности;
• переключение со старой версии;
• восстановление после сбоя;
• UI обновления;
• жизнь самого updater.

ClickOnce закрывает изрядную часть этого уже существующей моделью.

flowchart LR
    subgraph Custom[Что несёт собственный updater]
        C1["Обнаружение новой версии"]
        C2["Загрузка"]
        C3["Проверка целостности"]
        C4["Переключение"]
        C5["Восстановление после сбоя"]
        C1 --> C2 --> C3 --> C4 --> C5
    end

    subgraph Click[Что можно отдать ClickOnce]
        K1["Обнаружение новой версии"]
        K2["Получение и проверка"]
        K3["Переключение"]
        K1 --> K2 --> K3
    end

Разумеется, это не «можно всё что угодно». Но «достаточного обновления», которое нужно внутреннему приложению, ClickOnce закрывает довольно легко.

6.3 Приложения реже сталкиваются друг с другом

Приложения ClickOnce изолированы по приложению, пользователю и версии.

Поэтому классика вроде

• конфликта версий общих компонентов;
• поломки другого приложения из-за перезаписи какого-то DLL;
• грязного окружения после ручной подмены файлов

случается реже.

6.4 Легко публиковать из Visual Studio

ClickOnce хорошо стыкуется с публикацией Visual Studio: до раздачи короткий путь.

Ещё до отдельной сложности вроде MSI authoring легко выстроить цикл:

• сначала опубликовать;
• сначала раздать;
• сначала запустить обновления;
• сначала получить обратную связь с площадки.

Минимальная процедура публикации

Одной концепции мало, поэтому ниже — конкретные шаги. Для десктопных Windows-приложений на .NET Core 3.1 / .NET 5 и новее используется не старый Publish Wizard, а средство публикации (Publish tool). Оно есть в Visual Studio 2019 версии 16.8 и новее и в Visual Studio 2022. У приложений на .NET Framework мастер другой, шаги не совпадают.

1. В Обозревателе решений щёлкните проект правой кнопкой и выберите «Опубликовать». Из меню: «Сборка» → «Опубликовать».
2. Если профиль публикации уже есть, откроется страница «Публикация» — выберите «Создать».
3. На странице выбора типа назначения выберите «Папка».
4. На следующей странице «Конкретный целевой объект» выберите «ClickOnce».
5. Введите путь публикации или выберите его через «Обзор». Это место, куда записываются артефакты сборки.
6. На странице «Расположение установки» укажите, откуда пользователи будут ставить приложение. Оно может не совпадать с путём из шага 5 — об это чаще всего спотыкаются в первый раз. Варианты: веб-сайт, UNC-ресурс, CD / DVD / USB.
7. На странице «Параметры» решите, нужна ли автономная работа. Если да, приложение появится в меню «Пуск» и будет автоматически обновляться при публикации новой версии. По умолчанию источник обновлений совпадает с расположением установки. Другой источник задаётся в параметрах обновления на этой же странице. Указанное здесь расположение станет deploymentProvider из раздела 9.6.
8. Ссылки в верхней части той же страницы «Параметры» позволяют задать файлы, включаемые в распространение (Application Files), пакеты предварительных требований (Prerequisites) и прочие параметры. Здесь же — версия публикации и автоматическое увеличение номера при каждой публикации.
9. На странице «Подписание манифестов» укажите, подписывать ли манифесты и каким сертификатом. Это связано с разделом 9.5.
10. На странице «Конфигурация» выберите конфигурацию сборки, зависящее от платформы развёртывание или автономное (self-contained), и идентификатор целевой среды выполнения.
11. «Готово» сохраняет профиль; на странице «Сводка» нажмите «Опубликовать» — выполнятся сборка и публикация. Со второго раза достаточно нажать «Опубликовать» на этой странице.

На практике заранее важно знать два момента.

• Версия публикации независима для каждого профиля ClickOnce. Если профили для проверки и для продакшена разделены, номера версий нужно вести по каждому отдельно.
• Средство публикации создаёт профиль .pubxml. При сборке из командной строки MSBuild указывают этот .pubxml. Это входная точка, когда публикацию кладут в CI.

6.5 Перенос настроек тоже относительно прямой

Если используется стандартный провайдер настроек приложения, у ClickOnce есть механизм слияния настроек предыдущей версии с новой при обновлении.

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

7. Где подходит

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

Конкретные примеры хорошего совпадения:

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

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

Дерево решения «подходит / нет»

flowchart TD
    S["Собрать требования"]
    Q1{"Это десктопное .NET-приложение,<br/>например WinForms / WPF?"}
    Q2{"Хватает per-user распространения?"}
    Q3{"Нужно ставить обычным пользователям?"}
    Q4{"Можно раздавать через веб / файловый ресурс?"}
    Q5{"Можно не делать слишком глубокий UX обновления?"}
    G["ClickOnce — очень сильный кандидат"]
    O["Сравнить другие способы"]

    S --> Q1
    Q1 -- нет --> O
    Q1 -- да --> Q2
    Q2 -- нет --> O
    Q2 -- да --> Q3
    Q3 -- нет --> O
    Q3 -- да --> Q4
    Q4 -- нет --> O
    Q4 -- да --> Q5
    Q5 -- да --> G
    Q5 -- нет --> O

8. Где не подходит

С другой стороны, ситуации, где ClickOnce лучше не натягивать, тоже ясны.

8.1 Нужен machine-wide install

ClickOnce по основе — per-user.

• нужна общая установка на всех пользователей;
• хочется класть в Program Files;
• нужно ставить и сопровождать на уровне всей машины.

Тогда естественнее MSI, а не ClickOnce.

8.2 Служба Windows / драйвер / расширение оболочки / серьёзная регистрация COM

Это уже глубокое вмешательство в ОС.

• служба Windows;
• драйвер;
• in-process shell extension;
• конфигурация, которая предполагает систематическую регистрацию COM.

Как только появляются такие требования, вы выходите из мира «легко раздать» ClickOnce.

8.3 Нужен package identity

Одна из причин выбрать MSIX — получить package identity.

ClickOnce в эту сторону не идёт. Если нужны modern packaging или функции Windows, завязанные на package identity, приоритет у MSIX.

8.4 UX обновления и каналы доставки — часть продукта

Например:

• каналы stable / beta / preview;
• поэтапная доставка;
• подстройка доли раскатки по телеметрии;
• тонкое управление фоновой загрузкой;
• своя стратегия отката;
• сложный жизненный цикл самого updater.

Как только этого захочется, встроенного обновления ClickOnce не хватит.

8.5 Инструменты, которым достаточно просто положить файлы

Бывает и наоборот — всё может быть ещё проще.

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

Тогда xcopy иногда даёт меньше трения.

К какому способу склоняться при каких требованиях

flowchart LR
    A1["Установка на всех пользователей"] --> B1["MSI / отчасти MSIX"]
    A2["служба / драйвер / расширение оболочки / серьёзный COM"] --> B2["MSI / специализированный установщик"]
    A3["Нужен package identity"] --> B3["MSIX"]
    A4["Поэтапная доставка / каналы / свой UX"] --> B4["Собственный updater"]
    A5["Достаточно просто положить"] --> B5["xcopy"]

ClickOnce не универсален ни «сверху», ни «снизу». Зато он силён на задачах как раз той сложности, на которую рассчитан.

9. Где на практике легко застрять

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

9.1 Не смотрите на него как на «обычный установщик»

ClickOnce — не модель, в которой файлы удобно класть вручную в фиксированный каталог установки.

Реальные файлы попадают в кэш, которым управляет ClickOnce, и изолируются по версиям. Поэтому он плохо стыкуется с:

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

ClickOnce — не способ, которым человек раскладывает файлы, а способ, которым состояние распространения держат манифесты.

9.2 Многие старые статьи про ClickOnce написаны про .NET Framework

Здесь нужна осторожность.

Даже сейчас в топе поиска много статей эпохи .NET Framework. В текущем .NET картина другая.

• в .NET Core 3.1 / .NET 5 / .NET 6 API ApplicationDeployment напрямую не вызвать;
• начиная с .NET 7 часть свойств развёртывания можно читать через переменные окружения;
• если манифесты правят вручную, базовый инструмент — dotnet-mage.exe;
• и со стороны Visual Studio материалы про старый Publish Wizard иногда уже не проходят как есть.

Даже если кажется, что «ClickOnce я знаю», безопаснее не реализовывать по старой памяти.

9.3 Предварительные требования думайте отдельно

Сам ClickOnce — модель распространения, но приложению для работы могут быть нужны предварительные требования.

• подходящий runtime;
• дополнительные распространяемые компоненты;
• прочие зависимости.

Тут помогает конфигурация bootstrapper с setup.exe. Если оставить это размытым, получается «через ClickOnce раздали, а не запускается».

9.4 Перенос настроек зависит от того, что и как вы храните

Со стандартным провайдером перенос при обновлении относительно прямой. Но если есть:

• свой провайдер настроек;
• расчёт на roaming;
• самостоятельно изменённое место хранения;
• сильное изменение структуры настроек между версиями,

«само» это не переедет.

9.5 Не относитесь легко к подписи и пути обновления

У ClickOnce есть механизмы раздачи и обновления, но ответственность за безопасность от этого не исчезает.

Особенно в продакшене заранее стоит собрать:

• как управлять сертификатом подписи;
• как показывать имя издателя;
• как управлять источником обновлений;
• как развести тестовую самоподпись и продакшен-подпись.

flowchart TD
    Cert["Сертификат подписи кода"]
    AppMan["Манифест приложения"]
    DepMan["Манифест развёртывания"]
    Verify["Проверка на клиенте"]
    Run["Обновление / запуск"]
    Tamper["Подделка манифеста"]
    Stop["Остановка при неудачной проверке"]

    Cert --> AppMan
    Cert --> DepMan
    AppMan --> Verify
    DepMan --> Verify
    Verify --> Run
    Tamper -. проверка не прошла .-> Stop

«Есть автообновление = можно не беспокоиться» — неверно. Отдельно нужно понять, чему вы доверяете и как это доверие поддерживаете.

9.6 Если переносите место публикации, пересмотрите deploymentProvider

Момент неброский, но на практике в него часто попадают.

Уже установленное приложение ClickOnce ходит за обновлениями туда, куда указывает deploymentProvider в манифесте развёртывания. То есть даже если скопировать всю папку публикации на другой URL или в другой общий ресурс, без обновления deploymentProvider клиент может продолжать смотреть на старое место.

А если манифест меняли руками, нужна повторная подпись.

Рабочий поток от публикации до появления обновления у клиента

flowchart TD
    Build["Сборка"]
    AppManifest["Создание нового манифеста приложения"]
    SignApp["Подпись манифеста приложения"]
    UpdateDep["Обновление манифеста развёртывания до новой версии"]
    SignDep["Подпись манифеста развёртывания"]
    Publish["Выкладка в место публикации"]
    Client["Клиент обнаруживает обновление"]

    Build --> AppManifest --> SignApp --> UpdateDep --> SignDep --> Publish --> Client

В эксплуатации ClickOnce важнее не то, положили ли файлы, а то, согласованы ли манифесты и подписи.

10. Итог

Одной фразой ClickOnce — это

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

Сильные стороны в основном такие:

• легко раздавать обычным пользователям;
• есть встроенная модель обновления;
• проще обновлять только изменившуюся часть;
• проще изолировать приложения и версии;
• проще публиковать из Visual Studio;
• хорошо ложится на внутренние бизнес-приложения.

Но он не универсален.

• machine-wide install;
• служба / драйвер / расширение оболочки;
• серьёзная регистрация COM;
• package identity;
• свои каналы или поэтапная доставка;
• UX обновления как ценность продукта.

При таких требованиях смотрят не ClickOnce, а MSI / MSIX / собственный updater.

ClickOnce — это не простой установщик на все случаи, но на подходящих задачах он и сегодня очень силён.

Если вы хотите раздавать

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

ClickOnce входит в число очень сильных кандидатов.

11. Связанные статьи

• Как выбрать способ распространения Windows-приложения — MSI/MSIX/ClickOnce/xcopy/собственный updater
• Безопасность автообновления - почему одного HTTPS недостаточно
• Когда на Windows действительно требуются права администратора — UAC, защищённые области и как это определить на этапе проектирования

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

Страницы тем рядом с этой. От статьи можно перейти к услугам и другим материалам.

Технические темы по Windows

Вход в технические темы по разработке Windows, разбору сбоев и работе с уже существующим кодом.

Услуги, связанные с этой темой

Эта статья связана со следующими страницами услуг. Заходите с ближайшего входа.

Разработка Windows-приложений

Для внутренних бизнес-приложений, инструментов настройки оборудования, доработки существующего ПО то, какой из вариантов — ClickOnce / MSI / MSIX / xcopy — даст меньше трения, сильно зависит от того, насколько это собрано до начала реализации.

Смотреть услугу Связаться с нами

Техническая консультация и ревью архитектуры

Вопросы вроде «хватит ли ClickOnce», «не лучше ли опереться на MSIX или MSI», «оставить встроенное автообновление или писать своё» проще решать, если собрать их до начала реализации.

Смотреть услугу Связаться с нами

Профиль автора

Го Комура

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

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

Смотреть профиль Связаться с нами

12. Источники

• Microsoft Learn - ClickOnce deployment and security
• Microsoft Learn - ClickOnce for .NET on Windows
• Microsoft Learn - Deploy a .NET Windows Desktop app with ClickOnce
• Microsoft Learn - An overview of Package Identity in Windows apps
• Microsoft Learn - How ClickOnce performs application updates
• Microsoft Learn - Choosing a ClickOnce update strategy
• Microsoft Learn - ClickOnce deployment manifest
• Microsoft Learn - ClickOnce application manifest
• Microsoft Learn - ClickOnce cache overview
• Microsoft Learn - ClickOnce and application settings
• Microsoft Learn - Install prerequisites with a ClickOnce application
• Microsoft Learn - ClickOnce and Authenticode
• Microsoft Learn - Security, versioning, and manifest issues in ClickOnce deployments

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

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

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

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

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

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

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

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

Что такое ClickOnce?

Это технология распространения десктопных .NET-приложений для Windows: приложение ставится отдельно на каждого пользователя, вместе с автоматическим обновлением. Официально её описывают как технологию распространения Windows-приложений, которые можно установить и запустить при минимальном участии пользователя и которые умеют обновляться сами. На практике это модель распространения: вокруг манифестов собраны раздача, обновление и управление кэшем. Файлы живут в безопасной области кэша, изолированной по приложению, пользователю и версии.

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

В актуальном .NET ClickOnce по-прежнему обычный кандидат. В Visual Studio для .NET Core 3.1 и .NET 5+ используется средство публикации (Publish tool); если манифесты правят вручную — `dotnet-mage.exe`. Но это уже не эпоха .NET Framework: в .NET Core 3.1 / .NET 5 / .NET 6 API ApplicationDeployment напрямую не вызвать, а начиная с .NET 7 часть свойств развёртывания читают через переменные окружения. Реализацию лучше не начинать по памяти из старых статей.

Для каких приложений подходит ClickOnce?

Особенно хорошо он ложится на внутренние бизнес-приложения WinForms / WPF, когда нужно раздавать обычным пользователям без прав администратора, хватает per-user распространения и хочется встроенного обновления. Канала вроде веб-сайта или файлового ресурса достаточно. Наоборот, для machine-wide install на всех пользователей, служб Windows, драйверов, расширений оболочки, серьёзной регистрации COM, требований package identity, а также если нужно держать каналы обновления и поэтапную доставку — ClickOnce не тот инструмент. Тогда смотрят MSI / MSIX / собственный updater.

Как устроено автоматическое обновление ClickOnce?

Проверка обновления начинается с манифеста развёртывания (.application). Приложение читает его и смотрит: есть ли новая версия, обязательное ли это обновление и откуда его брать. Дальше работает file patching: новый манифест приложения сравнивают с текущим и качают только изменившиеся файлы, без полной повторной загрузки. В кэше ClickOnce текущая и предыдущая версии лежат раздельно; новую версию сначала собирают целиком и только потом переключаются на неё. Если сети нет, проверка обновлений пропускается, приложение просто запускается.

Об авторе

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

Го Комура

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

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