ClickOnce란 무엇인가 - 구조, 업데이트, 어울리는 장면・어울리지 않는 장면을 실무 시점에서 정리

Windows의 .NET 데스크톱 앱을 배포하는 이야기가 되면, MSI나 MSIX의 그림자에서 수수하게 몇 번이나 이름이 나오는 것이 ClickOnce입니다.

다만 여기서 거칠게,

오래된 기술이니까 이제 사용하지 않는다
반대로, 간단해 보이니까 뭐든지 ClickOnce로 갈 수 있다

중 어느 쪽으로 기울여도 대개 빗나갑니다.

ClickOnce는 뭐든지 할 수 있는 만능 installer가 아닙니다. 한편으로 사내용의 .NET 업무 앱을 표준 사용자에게 배포하고, 업데이트까지 포함해 저비용으로 돌리고 싶은 장면에서는 지금도 꽤 유력합니다.

이 글에서는 ClickOnce가 무엇인지, 어떻게 동작하는지, 무엇이 뛰어나고, 어디서 무리가 나오는지를 Mermaid 그림을 많이 넣으면서 실무 시점에서 정리합니다. 내용은 2026년 4월 시점에서 확인할 수 있는 Microsoft Learn의 정보를 주된 전제로 하고 있습니다.

그림은 개념도입니다. Mermaid 대응의 Markdown 환경에서는 그림으로서 표시됩니다.

1. 먼저 결론

ClickOnce를 한마디로 말하면, .NET의 Windows 데스크톱 앱을 이용자 단위로 간단히 배포하고, 자동 업데이트까지 포함해 돌리기 위한 배포 기술입니다.

어울리는 것은 예를 들어 다음입니다.

WinForms / WPF 등의 사내용 업무 앱
표준 사용자로 도입하고 싶다
per-user 배포로 충분
업데이트를 built-in으로 가지고 싶다
배포 경로가 Web 사이트나 파일 공유로 충분

반대로, 다음이라면 처음부터 다른 방식을 보는 편이 안전합니다.

전 사용자용의 machine-wide install
Windows service, driver, in-process shell extension, 진한 COM 등록
package identity가 필요
업데이트 채널, 단계 배신, 독자 rollback UX까지 쥐고 싶다
인스톨러로서 OS에 깊게 들어가는 책무가 크다

요컨대 ClickOnce는 간단 배포와 간단 업데이트에는 강하지만, OS 통합이 무거운 안건에는 어울리지 않는 방식입니다.

먼저는 위치를 한 장으로 본다

flowchart TD
    A["Windows 앱을 배포하고 싶다"]
    B{"OS에 깊게 통합할 요건이 있는가"}
    C["MSI / MSIX 측에서 생각한다"]
    D{".NET의 Windows 데스크톱 앱에서<br/>per-user 배포로 충분한가"}
    E{"표준 사용자에게 배포하고 싶은가"}
    F{"built-in 업데이트로 충분한가"}
    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는 다음을 한꺼번에 돌보는 배포 모델입니다.

어느 버전을 배포할지
어느 파일이 그 버전에 포함되는지
어떻게 업데이트를 검출할지
어디서 업데이트를 취득할지
이용자별의 안전한 장소에 어떻게 보유할지
기동 시에 정합성을 어떻게 확인할지

즉, 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를 구성하는 것

ClickOnce의 구조를 이해할 때는 다음 4가지를 보면 꽤 정리하기 쉽습니다.

요소	역할
배치 매니페스트 (`.application`)	지금 배포해야 할 버전, 업데이트 장소, 업데이트 방법 등을 나타낸다
애플리케이션 매니페스트 (`*.exe.manifest`)	그 버전의 앱 본체, 의존 파일, 해시, 엔트리 포인트 등을 나타낸다
애플리케이션 파일	`exe`, `dll`, config, 데이터 파일 등
`setup.exe`(임의)	전제 조건을 확인・도입하는 bootstrapper. 필요한 런타임이나 의존물이 있을 때 사용한다

여기서 핵심이 되는 것은 2 종류의 매니페스트입니다.

배치 매니페스트는 「이 앱의 지금의 정답은 어느 버전인가」를 나타낸다
애플리케이션 매니페스트는 「그 버전의 내용물은 무엇인가」를 나타낸다

즉, ClickOnce의 업데이트 판정은 먼저 배치 매니페스트에서 시작되고, 실제로 무엇을 떨어뜨릴지는 애플리케이션 매니페스트가 쥡니다.

4 요소의 관계

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의 주역이 아닙니다. 이것은 전제 조건을 확인・도입하는 보조역입니다.

예를 들어, 올바른 .NET 런타임이나 추가의 재배포 컴포넌트가 필요할 때는 setup.exe가 먼저 그것을 갖추고, 그 후에 ClickOnce 본체의 배포에 들어갑니다.

4. 인스톨부터 기동까지의 흐름

ClickOnce의 흐름을 실무용으로 꽤 단순화하면 다음입니다.

사용자가 Web 페이지나 파일 공유상의 setup.exe 또는 .application을 연다
setup.exe를 사용하는 구성이라면, 전제 조건을 확인해 부족분을 넣는다
ClickOnce가 배치 매니페스트를 읽는다
배치 매니페스트가 가리키는 애플리케이션 매니페스트를 읽는다
필요한 파일을 취득해 이용자별의 ClickOnce 캐시로 배치한다
오프라인 이용 있음의 구성이라면 시작 메뉴나 앱 일람에 등록한다
그 후는 ClickOnce 관리하에서 앱을 기동한다

포인트는 Program Files에 평범한 installer처럼 두는 발상이 아니라는 것입니다.

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에는 크게 2가지 보이는 방식이 있습니다.

온라인 전용: 공개 장소를 기점으로 실행하는 형. 상설 인스톨 느낌은 옅다
오프라인 이용 있음: 이용자의 단말에 도입되고, 시작 메뉴에서도 기동할 수 있는 형

사내 업무 앱에서는 실무상 오프라인 이용 있음을 선택하는 경우가 많습니다.

flowchart LR
    subgraph Online[온라인 전용]
        O1["공개 장소를 기점으로 기동"]
        O2["상설 인스톨 느낌은 옅다"]
        O3["네트워크 전제가 되기 쉽다"]
        O1 --> O2 --> O3
    end

    subgraph Offline[오프라인 이용 있음]
        F1["사용자 영역에 도입"]
        F2["시작 메뉴 등록"]
        F3["로컬에서 기동"]
        F4["지정 타이밍에 업데이트 확인"]
        F1 --> F2 --> F3 --> F4
    end

5. 업데이트의 구조

ClickOnce의 가장 알기 쉬운 강점은 역시 업데이트 모델이 built-in이라는 것입니다.

업데이트 판정은 배치 매니페스트에서 시작된다

ClickOnce 앱은 배치 매니페스트를 읽어서,

새로운 버전이 있는가
필수 업데이트인가
어디서 취득하는가

를 확인합니다.

그 위에서 업데이트가 시작되면, ClickOnce는 file patching을 사용해 중복된 재다운로드를 피합니다. 감각으로는 신 버전의 애플리케이션 매니페스트와 현행 버전을 비교해, 바뀐 파일만 가지러 간다고 생각하면 실무에서는 이해하기 쉽습니다.

업데이트 확인의 사고방식으로서는 다음 3 패턴으로 정리하면 알기 쉽습니다.

기동 전에 확인한다
기동 후에 확인한다
앱 측에서 「업데이트 확인」 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[이용자 A의 ClickOnce 캐시]
        APrev["이전 버전"]
        ACur["현행 버전"]
        AData["설정 / 데이터"]
    end

    subgraph UB[이용자 B의 ClickOnce 캐시]
        BPrev["이전 버전"]
        BCur["현행 버전"]
        BData["설정 / 데이터"]
    end

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

여기서의 포인트는 2가지입니다.

다른 사용자와 섞이기 어렵다
다른 버전과 충돌하기 어렵다

이른바 DLL Hell을 피하기 쉬운 것은 이 구조가 큽니다.

6. ClickOnce가 뛰어난 점

ClickOnce의 좋은 점은 「간단히 배포할 수 있다」만이 아닙니다. 실무에서 효과가 있는 것은 대체로 다음입니다.

6.1 표준 사용자에게 배포하기 쉽다

ClickOnce는 per-user 전제의 배포와 상성이 좋고, 관리자 권한 없이 도입하기 쉬운 것이 큽니다.

사내 업무 앱에서 자주 있는 것은,

이용자는 표준 사용자
IT 부문에 매번 인스톨 의뢰하고 싶지 않다
하지만 업데이트는 멈추고 싶지 않다

는 상황입니다.

이 조건에서는 ClickOnce는 꽤 강합니다. 「각 이용자의 영역으로 안전하게 업데이트 포함으로 들어간다」라는 전제가 처음부터 맞습니다.

6.2 업데이트를 자체 구현하지 않아도 된다

자동 업데이트를 0부터 만들면 겉보기 이상으로 할 일이 늘어납니다.

신 버전 확인
다운로드
정합성 확인
구 버전과의 전환
실패 시의 복구
업데이트 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

물론 뭐든 자유롭게 할 수 있는 것은 아닙니다. 다만 사내용 앱에서 필요한 「충분한 업데이트」는 꽤 만족시키기 쉽습니다.

6.3 앱끼리 충돌하기 어렵다

ClickOnce 앱은 앱별・이용자별・버전별로 분리됩니다.

그래서 옛날 방식의,

공유 컴포넌트의 버전 경합
어딘가의 DLL을 덮어써서 다른 앱이 망가진다
수동 교체로 환경이 더러워진다

와 같은 사고를 일으키기 어렵습니다.

6.4 Visual Studio에서 내기 쉽다

ClickOnce는 Visual Studio의 발행 기능과 상성이 좋고, 배포까지의 거리가 짧은 것도 이점입니다.

MSI authoring과 같은 다른 어려움에 들어가기 전에,

우선 발행하고
우선 배포하고
우선 업데이트를 돌리고
우선 현장의 피드백을 얻는다

는 흐름을 만들기 쉽습니다.

6.5 설정 이관도 비교적 자연스럽다

기본의 애플리케이션 설정 프로바이더를 사용하는 경우, ClickOnce는 업데이트 시에 이전 버전의 설정을 신 버전으로 머지하는 구조를 가지고 있습니다.

다만 여기는 기본 설정 프로바이더 전제입니다. 독자 설정 저장이나 독자 프로바이더, 저장처의 변경까지 들어가면 당연히 그대로는 되지 않습니다.

7. 어울리는 장면

ClickOnce가 특히 어울리는 것은 대체로 다음과 같은 안건입니다.

상황	ClickOnce와 상성이 좋은 이유
사내용 WinForms / WPF 업무 앱	표준 사용자 배포와 자동 업데이트가 맞물린다
이용자 단위로 도입할 수 있으면 충분	per-user 배포가 자연스럽다
Web 사이트나 UNC 공유로 배포하고 싶다	배포 경로가 심플
업데이트 빈도가 월차~주차 정도	built-in 업데이트로 충분히 돌리기 쉽다
업데이트 UI를 제품 가치로서 다듬고 싶지 않다	기존의 업데이트 모델을 사용할 수 있다

실무에서 꽤 상성이 좋은 구체 예를 들면 다음입니다.

사내의 업무 입력 앱
견적・수주・재고 등의 데스크톱 업무 도구
장치 설정용의 보조 앱
영업소・공장・백오피스에 배포하는 사내 전용 클라이언트
업데이트는 원하지만 전용 updater를 만들 정도는 아닌 앱

이런 앱에서는 배포와 업데이트를 심플하게 하는 것 자체가 가치입니다. ClickOnce는 그 가치에 꽤 자연스럽게 응합니다.

어울리는지의 판단 나무

flowchart TD
    S["요건을 정리한다"]
    Q1{"WinForms / WPF 등의<br/>.NET 데스크톱 앱인가"}
    Q2{"per-user 배포로 충분한가"}
    Q3{"표준 사용자에게 넣고 싶은가"}
    Q4{"Web / 파일 공유로 배포할 수 있는가"}
    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 전제로 넣고 싶다
단말 전체에 도입・관리하고 싶다

라면 ClickOnce가 아니라 MSI 등이 자연스럽습니다.

8.2 Windows service / driver / shell extension / 진한 COM 등록

이 부근은 OS에 깊게 만지는 이야기입니다.

Windows service
driver
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 채널
단계 배신
telemetry를 보면서 롤아웃률 조정
배경 다운로드의 세세한 제어
독자의 rollback 전략
updater 자체의 복잡한 라이프사이클

까지 원하게 되면 ClickOnce의 built-in 업데이트로는 부족해집니다.

8.5 두기만 하는 운용으로 충분한 도구

반대로 더 단순해도 좋은 케이스도 있습니다.

폴더째로 두면 동작한다
업데이트도 수동 교체로 좋다
USB로 건넨다
폐역에서 단순함이 최우선

이라면 xcopy 배포 쪽이 마찰이 적은 경우도 있습니다.

어느 요건이면 다른 방식으로 기울이는가

flowchart LR
    A1["전 사용자용 도입"] --> B1["MSI / 일부 MSIX"]
    A2["service / driver / shell extension / 진한 COM"] --> B2["MSI / 전용 installer"]
    A3["package identity가 필요"] --> B3["MSIX"]
    A4["단계 배신 / 채널 / 독자 UX"] --> B4["독자 updater"]
    A5["두기만 해도 충분"] --> B5["xcopy"]

즉, ClickOnce는 위에도 아래에도 만능은 아닙니다. 딱 좋은 복잡함의 안건에 강한 방식입니다.

9. 실무에서 빠지기 쉬운 점

ClickOnce는 편리하지만 거칠게 들어가면 조금 빠집니다. 특히 다음은 먼저 짚어두면 편합니다.

9.1 「평범한 installer」와 같은 감각으로 보지 않는다

ClickOnce는 고정의 인스톨처로 인간이 직접 관리하기 쉬운 형태로 두는 모델이 아닙니다.

실체는 ClickOnce가 관리하는 캐시에 들어가며, 버전별로 분리됩니다. 그래서,

고정 EXE 패스를 전제로 한 운용
손으로 직접 덮어쓰는 운용
실체 파일의 장소를 사람이 쥐는 운용

과는 상성이 좋지 않습니다.

ClickOnce는 파일 배치를 사람이 관리하는 방식이 아니라, 배포 상태를 매니페스트로 관리하는 방식입니다.

9.2 오래된 ClickOnce 기사는 .NET Framework 전제의 것이 많다

여기는 꽤 중요합니다.

지금도 검색 상위에는 .NET Framework 시대의 ClickOnce 기사가 많이 나옵니다. 다만, 지금의 .NET에서는 사정이 조금 다릅니다.

.NET Core 3.1 / .NET 5 / .NET 6에서는 ApplicationDeployment API를 그대로는 사용할 수 없다
.NET 7 이후에서는 일부의 배치 프로퍼티를 환경 변수 경유로 읽을 수 있다
수동으로 매니페스트를 다룬다면 dotnet-mage.exe가 전제가 된다
Visual Studio 측도 옛날의 Publish Wizard 전제의 이야기가 그대로 통하지 않는 경우가 있다

즉, 「ClickOnce는 알고 있다」고 여겨도 오래된 기억 그대로 구현하지 않는 편이 안전합니다.

9.3 전제 조건은 별도로 생각한다

ClickOnce 자체는 배포 모델이지만, 앱이 동작하기 위해서는 전제 조건이 필요한 경우가 있습니다.

대응 런타임
추가의 재배포 컴포넌트
기타 의존물

이때 setup.exe를 사용하는 bootstrapper 구성이 효과적입니다. 반대로 여기를 애매하게 하면 「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 데스크톱 앱을, per-user로 간단히 배포하고, 업데이트까지 저비용으로 돌리기 위한 구조

입니다.

뛰어난 것은 주로 다음 점입니다.

표준 사용자에게 배포하기 쉽다
built-in의 업데이트 모델이 있다
변경분만의 업데이트가 쉽다
앱과 버전을 분리하기 쉽다
Visual Studio에서 발행하기 쉽다
사내용 업무 앱과 상성이 좋다

다만 만능은 아닙니다.

machine-wide install
service / driver / shell extension
진한 COM 등록
package identity
독자 채널이나 단계 배신
업데이트 UX를 제품 가치로서 다듬는다

와 같은 요건이 있다면 ClickOnce가 아니라 MSI / MSIX / 독자 updater 측에서 생각해야 합니다.

즉, ClickOnce는 뭐든 들어가는 간이 installer가 아닙니다. 그 대신 어울리는 안건에서는 지금도 꽤 강합니다.

만약 배포하고 싶은 것이

.NET의 Windows 업무 앱으로
이용자 단위의 도입으로 충분하고
표준 사용자에게 배포하고 싶어서
업데이트를 자체적으로 가지고 싶지 않다

라면 ClickOnce는 꽤 유력한 후보에 들어갑니다.

11. 관련 기사

12. 참고 자료

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

Windows 앱 개발

상주 처리, 장비 연동, 운영 로그, 유지 보수 가능한 구조가 필요한 Windows 데스크톱 애플리케이션을 지원합니다.

서비스 보기 문의하기

Windows 소프트웨어 유지 보수 & 현대화

기존 Windows 소프트웨어에 대한 단계적 업그레이드, 기능 추가, 64비트 대응, 유지 보수 가능한 재구조화를 지원합니다.