Что такое ClickOnce - механизм работы, обновления и случаи применения с практической точки зрения

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

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

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

в большинстве случаев вы ошибётесь.

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

В этой статье мы разберём, что такое ClickOnce, как он работает, в чём его сильные стороны и где начинаются трудности - с практической точки зрения и с большим количеством диаграмм Mermaid. Материал в основном опирается на информацию Microsoft Learn, доступную по состоянию на апрель 2026 года.

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

Оглавление

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

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

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

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

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

И наоборот, при следующих требованиях безопаснее сразу смотреть на другой способ:

• machine-wide install для всех пользователей;
• служба Windows, драйвер, встроенное расширение оболочки, плотная регистрация 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 - это технология распространения Windows-приложений от Microsoft. Официально она описывается как технология распространения Windows-приложений, которые можно установить и запустить при минимальном участии пользователя и которые способны обновляться самостоятельно.

Важно не рассматривать ClickOnce просто как «разновидность инсталлятора».

По сути ClickOnce - это модель распространения, которая берёт на себя заботу обо всём следующем.

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

Ядро ClickOnce - не сам setup.exe, а, ближе к сути, механизм, объединяющий вокруг манифестов распространение, обновление и управление кэшем.

Даже в текущем .NET сам по себе ClickOnce остаётся обычным кандидатом. В Visual Studio для .NET Core 3.1 и .NET 5 и новее используется инструмент Publish, а при ручной работе с манифестами применяется dotnet-mage.exe.

Обязанности, которые берёт на себя ClickOnce

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

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

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

Кратчайший путь понять механизм ClickOnce - разобраться в этих четырёх элементах.

Ядро здесь - два вида манифестов.

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

Иными словами, определение необходимости обновления в 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

Достоинства 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 легко выстроить цикл:

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

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

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

Однако это работает при условии стандартного провайдера настроек. При собственном хранении настроек, собственном провайдере или изменённом месте хранения это, естественно, само собой не сработает.

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

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 не подходит

С другой стороны, ситуации, где не стоит насильно применять 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

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

Даже сегодня в топе поисковой выдачи много статей о ClickOnce времён .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 - 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, а при ручной работе с манифестами применяется 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.