Was ist ClickOnce? - Funktionsweise, Updates und wo es passt oder nicht, aus praktischer Sicht

Wenn es um die Verteilung von .NET-Desktopanwendungen unter Windows geht, taucht im Schatten von MSI und MSIX unauffällig, aber immer wieder ein Name auf: ClickOnce.

Schlägt man hier jedoch pauschal in eine der beiden Richtungen aus –

• es ist alte Technik, die wir nicht mehr verwenden
• oder umgekehrt: es sieht einfach aus, also kommen wir mit ClickOnce für alles durch

– liegt man meistens daneben.

ClickOnce ist kein Allzweck-Installer, der alles kann. Andererseits ist es auch heute noch eine sehr starke Option, wenn Sie eine interne .NET-Businessanwendung an Standardbenutzer verteilen und dabei auch die Updates kostengünstig mit abdecken wollen.

Dieser Artikel ordnet aus praktischer Sicht – mit vielen Mermaid-Diagrammen – ein, was ClickOnce ist, wie es funktioniert, worin es stark ist und wo es an seine Grenzen stößt. Die Inhalte stützen sich hauptsächlich auf Informationen von Microsoft Learn, die im April 2026 verfügbar waren.

Die Diagramme sind konzeptionell. In Markdown-Umgebungen mit Mermaid-Unterstützung werden sie als Grafiken dargestellt.

Zielgruppe

Dieser Artikel richtet sich an Entwickler, die überlegen, wie sie eine .NET-Windows-Desktopanwendung (WinForms / WPF) verteilen sollen, sowie an IT-Verantwortliche, die diese Verteilung und die Updates betreiben. Da davon ausgegangen wird, dass die Entscheidung für oder gegen ClickOnce noch offen ist, werden zunächst die Entscheidungsgrundlagen dargestellt; die eigentlichen Veröffentlichungsschritte finden Sie in Abschnitt 6.4.

Vorab zu klärende Begriffe

Im Text tauchen einige Begriffe unverändert auf Englisch auf. Damit Sie beim ersten Auftreten nicht stolpern, sind sie hier vorab zusammengefasst.

Inhaltsverzeichnis

1. Zuerst das Fazit
2. Was ist ClickOnce?
3. Woraus ClickOnce besteht
4. Der Ablauf von der Installation bis zum Start
5. Wie Updates funktionieren
6. Wo ClickOnce stark ist
7. Wo es passt
8. Wo es nicht passt
9. Häufige Stolperfallen in der Praxis
10. Zusammenfassung
11. Verwandte Artikel
12. Referenzlinks

1. Zuerst das Fazit

Kurz gesagt ist ClickOnce eine Verteilungstechnologie, um .NET-Windows-Desktopanwendungen einfach je Benutzer zu verteilen und dabei auch automatische Updates mit abzudecken.

Es passt zum Beispiel auf Fälle wie diese.

• Interne Businessanwendungen etwa in WinForms / WPF
• Sie möchten mit Standardbenutzern installieren
• Per-user-Verteilung reicht aus
• Sie möchten Updates built-in haben
• Als Verteilungsweg genügen Website oder Dateifreigabe

Umgekehrt ist es sicherer, bei folgenden Anforderungen von Anfang an ein anderes Verfahren zu prüfen.

• Machine-wide-Installation für alle Benutzer
• Windows-Dienst, Treiber, In-Process-Shell-Extension, umfangreiche COM-Registrierung
• package identity wird benötigt
• Sie möchten Update-Kanäle, gestaffelte Verteilung und eine eigene Rollback-UX selbst steuern
• Der Installer trägt als solcher eine große Verantwortung, tief in das OS einzugreifen

Kurz gesagt ist ClickOnce ein Verfahren, das bei einfacher Verteilung und einfachen Updates stark ist, sich aber nicht für Projekte mit tiefer OS-Integration eignet.

Zunächst die Einordnung auf einen Blick

flowchart TD
    A["Windows-App verteilen"]
    B{"Gibt es Anforderungen an tiefe OS-Integration?"}
    C["Von MSI / MSIX aus denken"]
    D{"Ist es eine .NET-Windows-Desktopanwendung,<br/>bei der per-user-Verteilung ausreicht?"}
    E{"Soll an Standardbenutzer verteilt werden?"}
    F{"Reicht ein built-in Update?"}
    G["ClickOnce ist eine starke Option"]
    H["Auch xcopy / eigenen Updater vergleichen"]

    A --> B
    B -- Ja --> C
    B -- Nein --> D
    D -- Nein --> H
    D -- Ja --> E
    E -- Nein --> H
    E -- Ja --> F
    F -- Ja --> G
    F -- Nein --> H

2. Was ist ClickOnce?

ClickOnce ist Microsofts Verteilungstechnologie für Windows-Apps. Offiziell wird es beschrieben als eine Verteilungstechnologie für Windows-basierte Apps, die sich mit minimaler Benutzerinteraktion installieren und ausführen lassen und die sich selbst aktualisieren können.

Wichtig ist dabei, ClickOnce nicht einfach als „eine Art Installer“ zu betrachten.

Tatsächlich ist ClickOnce ein Verteilungsmodell, das sich gebündelt um Folgendes kümmert.

• Welche Version verteilt wird
• Welche Dateien zu dieser Version gehören
• Wie Updates erkannt werden
• Woher Updates geholt werden
• Wie die App an einem sicheren, benutzerbezogenen Ort gehalten wird
• Wie beim Start die Integrität geprüft wird

Der Kern von ClickOnce ist nicht setup.exe selbst; näher am Wesen ist es, ClickOnce als einen Mechanismus zu betrachten, der Verteilung, Updates und Cache-Verwaltung gebündelt um Manifeste herum organisiert.

Auch mit dem aktuellen .NET bleibt ClickOnce selbst eine normale Option. In Visual Studio wird für .NET Core 3.1 und .NET 5 und später das Publish Tool verwendet; wer Manifeste manuell bearbeiten möchte, nutzt dotnet-mage.exe.

Die Verantwortlichkeiten, um die sich ClickOnce kümmert

flowchart LR
    CO["ClickOnce"]
    V["Welche Version verteilt wird"]
    U["Woher Updates geholt werden"]
    S["Sicherer, benutzerbezogener Speicherort"]
    I["Integrität prüfen und starten"]

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

3. Woraus ClickOnce besteht

Der schnellste Weg, die Funktionsweise von ClickOnce zu verstehen, führt über diese vier Elemente.

Den Kern bilden dabei die beiden Arten von Manifesten.

• Das Bereitstellungsmanifest drückt aus, „welche Version gerade die richtige für diese App ist“
• Das Anwendungsmanifest drückt aus, „was in dieser Version enthalten ist“

Das heißt: Die Update-Entscheidung von ClickOnce beginnt zuerst beim Bereitstellungsmanifest, während das Anwendungsmanifest bestimmt, was tatsächlich heruntergeladen wird.

Wie die vier Elemente zusammenhängen

flowchart LR
    Setup["setup.exe<br/>optional<br/>Voraussetzungen prüfen / installieren"]
    Deploy["Bereitstellungsmanifest (.application)<br/>welche Version verteilt wird<br/>Update-Ort / Update-Bedingungen"]
    App["Anwendungsmanifest (*.exe.manifest)<br/>Inhalt dieser Version<br/>Dateiliste / Hashes / Einstiegspunkt"]
    Files["App-Binärdateien<br/>exe / dll / config / data"]
    Cache["ClickOnce-Cache<br/>per-user / per-application"]

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

setup.exe ist nicht die Hauptrolle, sondern ein Helfer

setup.exe fällt oft ins Auge, ist aber nicht die Hauptrolle von ClickOnce. Es ist eine Helferrolle, die Voraussetzungen prüft und installiert.

Wird zum Beispiel die richtige .NET-Runtime oder eine zusätzliche redistributable Komponente benötigt, richtet setup.exe diese zuerst ein, bevor die eigentliche ClickOnce-Verteilung beginnt.

4. Der Ablauf von der Installation bis zum Start

Vereinfacht man den ClickOnce-Ablauf konsequent für die Praxis, ergibt sich Folgendes.

1. Der Benutzer öffnet setup.exe oder die .application-Datei auf einer Webseite oder Dateifreigabe
2. Bei einer Konfiguration mit setup.exe werden die Voraussetzungen geprüft und fehlende Teile installiert
3. ClickOnce liest das Bereitstellungsmanifest
4. Es liest das Anwendungsmanifest, auf das das Bereitstellungsmanifest verweist
5. Es holt die benötigten Dateien und legt sie im benutzerbezogenen ClickOnce-Cache ab
6. Bei einer Konfiguration mit Offline-Verfügbarkeit wird die App im Startmenü / in der App-Liste registriert
7. Danach startet die App unter der Verwaltung von ClickOnce

Der entscheidende Punkt ist, dass dies nicht der Gedanke ist, die App wie bei einem gewöhnlichen Installer in Program Files abzulegen.

ClickOnce-Apps landen in einem sicheren, benutzerbezogenen Cache-Bereich und werden je App und je Benutzer voneinander getrennt. Das ist ein großes Merkmal von ClickOnce.

Von der Installation bis zum ersten Start

sequenceDiagram
    participant U as Benutzer
    participant P as setup.exe / .application
    participant D as Bereitstellungsmanifest
    participant A as Anwendungsmanifest
    participant C as ClickOnce-Cache
    participant X as App-Binärdateien

    U->>P: Öffnen
    Note over U,P: In Konfigurationen mit setup.exe<br/>kommt zuerst die Prüfung der Voraussetzungen
    P->>D: Holen und lesen
    D->>A: Zielversion referenzieren
    A->>C: Benötigte Dateien holen, Integrität prüfen
    C->>X: Platzieren und starten

Nur online und mit Offline-Verfügbarkeit

ClickOnce bietet grob zwei Erscheinungsformen.

• Nur online: läuft ausgehend vom Veröffentlichungsort. Wirkt kaum wie eine dauerhafte Installation
• Mit Offline-Verfügbarkeit: wird auf dem Gerät des Benutzers installiert und lässt sich auch aus dem Startmenü starten

Bei internen Businessanwendungen wird in der Praxis meist mit Offline-Verfügbarkeit gewählt.

flowchart LR
    subgraph Online[Nur online]
        O1["Start ausgehend vom Veröffentlichungsort"]
        O2["Wirkt kaum wie eine dauerhafte Installation"]
        O3["Setzt tendenziell ein Netzwerk voraus"]
        O1 --> O2 --> O3
    end

    subgraph Offline[Mit Offline-Verfügbarkeit]
        F1["Installation im Benutzerbereich"]
        F2["Registrierung im Startmenü"]
        F3["Lokaler Start"]
        F4["Update-Prüfung zum festgelegten Zeitpunkt"]
        F1 --> F2 --> F3 --> F4
    end

5. Wie Updates funktionieren

Die klarste Stärke von ClickOnce ist nach wie vor, dass das Update-Modell built-in ist.

Die Update-Entscheidung beginnt beim Bereitstellungsmanifest

Eine ClickOnce-App liest das Bereitstellungsmanifest und prüft,

• ob eine neuere Version existiert,
• ob das Update verpflichtend ist, und
• von wo sie geholt wird.

Beginnt daraufhin das Update, vermeidet ClickOnce über file patching überflüssige erneute Downloads. Als Faustregel für die Praxis hilft die Vorstellung, dass das neue Anwendungsmanifest mit der aktuellen Version verglichen wird und nur die geänderten Dateien geholt werden.

Für den Gedanken der Update-Prüfung hilft eine Einteilung in diese drei Muster.

• Vor dem Start prüfen
• Nach dem Start prüfen
• Eine „Auf Updates prüfen“-UI in der App bereitstellen

Allerdings unterscheiden sich zwischen .NET Framework und .NET 5+ die verfügbaren APIs und die Konfigurations-UI. Wichtig ist, nicht allein aus der Erinnerung an alte ClickOnce-Artikel heraus zu implementieren.

Der Update-Ablauf

flowchart TD
    Start["App-Start"]
    Check["Bereitstellungsmanifest prüfen"]
    New{"Gibt es eine neuere Version?"}
    Run["Direkt starten"]
    Get["Neues Anwendungsmanifest holen"]
    Compare["Dateisignaturen / Hashes vergleichen"]
    Download["Geänderte Teile holen"]
    Switch["Neue Version materialisieren und umschalten"]
    Restart["Bei Bedarf nach Neustart mit neuer Version ausführen"]

    Start --> Check --> New
    New -- Nein --> Run
    New -- Ja --> Get --> Compare --> Download --> Switch --> Restart

Es hilft in der Praxis, sich auch die Prämisse zu merken, dass ohne Netzwerkverbindung die App ohne Update-Prüfung einfach direkt ausgeführt wird.

Versionen werden getrennt aufbewahrt

ClickOnce folgt weniger dem Gedanken „die aktuellen Dateien direkt an Ort und Stelle überschreiben“ als vielmehr dem Prinzip, die neue Version zunächst korrekt zu materialisieren und dann umzuschalten.

Darüber hinaus werden im ClickOnce-Cache die aktuelle und die vorherige Version getrennt aufbewahrt. Das ist einer der Gründe, warum die Umgebung selten verschmutzt und Versionskonflikte leicht vermieden werden.

flowchart TB
    subgraph UA[ClickOnce-Cache von Benutzer A]
        APrev["Vorherige Version"]
        ACur["Aktuelle Version"]
        AData["Einstellungen / Daten"]
    end

    subgraph UB[ClickOnce-Cache von Benutzer B]
        BPrev["Vorherige Version"]
        BCur["Aktuelle Version"]
        BData["Einstellungen / Daten"]
    end

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

Zwei Punkte sind hier entscheidend.

• Vermischt sich kaum mit anderen Benutzern
• Kollidiert kaum mit anderen Versionen

Dass sich das sogenannte DLL Hell leicht vermeiden lässt, liegt maßgeblich an dieser Struktur.

6. Wo ClickOnce stark ist

Die Stärke von ClickOnce beschränkt sich nicht auf „lässt sich einfach verteilen“. In der Praxis zahlen sich vor allem folgende Punkte aus.

6.1 Leicht an Standardbenutzer zu verteilen

ClickOnce passt gut zu einer auf per-user ausgelegten Verteilung, und der große Vorteil ist, dass sich die Installation leicht ohne Administratorrechte durchführen lässt.

Bei internen Businessanwendungen ist häufig folgende Situation anzutreffen:

• Die Benutzer sind Standardbenutzer
• Man möchte nicht jedes Mal eine Installationsanfrage an die IT-Abteilung stellen
• Aber Updates sollen trotzdem nicht ausbleiben

Unter diesen Bedingungen ist ClickOnce ziemlich stark. Die Grundannahme – „sicher und inklusive Updates in den Bereich jedes einzelnen Benutzers gelangen“ – passt von Anfang an.

6.2 Updates müssen nicht selbst implementiert werden

Baut man Auto-Update von Grund auf, wächst der Aufwand mehr, als es zunächst aussieht.

• Erkennung neuer Versionen
• Download
• Integritätsprüfung
• Umschalten von der alten Version
• Wiederherstellung bei Fehlern
• Update-UI
• Umgang mit dem Updater selbst

ClickOnce deckt einen großen Teil davon bereits mit seinem bestehenden Modell ab.

flowchart LR
    subgraph Custom[Verantwortlichkeiten bei einem eigenen Updater]
        C1["Erkennung neuer Versionen"]
        C2["Download"]
        C3["Integritätsprüfung"]
        C4["Umschalten"]
        C5["Wiederherstellung bei Fehlern"]
        C1 --> C2 --> C3 --> C4 --> C5
    end

    subgraph Click[An ClickOnce delegierbare Verantwortlichkeiten]
        K1["Erkennung neuer Versionen"]
        K2["Holen und Verifizieren"]
        K3["Umschalten"]
        K1 --> K2 --> K3
    end

Natürlich lässt sich nicht alles frei gestalten. Aber die „ausreichenden Updates“, die interne Apps benötigen, lassen sich damit gut erfüllen.

6.3 Apps kollidieren kaum untereinander

ClickOnce-Apps werden je App, je Benutzer und je Version getrennt.

Dadurch treten klassische Zwischenfälle wie

• Versionskonflikte gemeinsam genutzter Komponenten,
• das Überschreiben irgendeiner DLL, wodurch eine andere App kaputtgeht, oder
• die Verschmutzung der Umgebung durch manuelles Ersetzen

kaum auf.

6.4 Lässt sich leicht aus Visual Studio veröffentlichen

ClickOnce passt gut zur Publish-Funktion von Visual Studio, und die kurze Distanz bis zur Verteilung ist ebenfalls ein Vorteil.

Bevor man sich auf eine andere Schwierigkeit wie MSI Authoring einlässt, lässt sich leicht ein Ablauf etablieren:

• zuerst veröffentlichen,
• zuerst verteilen,
• zuerst Updates zum Laufen bringen und
• zuerst Feedback aus dem Feld einholen.

Die minimalen Schritte zum Veröffentlichen

Nur auf Konzeptebene bleibt es abstrakt, deshalb folgen hier auch die konkreten Schritte. Bei Windows-Desktopanwendungen für .NET Core 3.1 / .NET 5 und später wird nicht mehr der alte Publish Wizard verwendet, sondern das Publish Tool. Betroffen sind Visual Studio 2019 ab Version 16.8 sowie Visual Studio 2022. Bei .NET-Framework-Apps kommt ein anderer Wizard zum Einsatz, sodass sich die Schritte unterscheiden.

1. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf das Projekt und wählen Sie „Veröffentlichen“. Über das Menü erreichen Sie es alternativ über „Erstellen“ → „Veröffentlichen“.
2. Existiert bereits ein Veröffentlichungsprofil, öffnet sich die Seite „Veröffentlichen“; wählen Sie dort „Neu“.
3. Wählen Sie auf der Seite zur Auswahl des Zieltyps „Ordner“.
4. Wählen Sie auf der folgenden Seite „Spezifisches Ziel“ die Option „ClickOnce“.
5. Geben Sie den Zielpfad ein oder wählen Sie ihn über „Durchsuchen“ aus. Dies ist der Ort, an den die Build-Ergebnisse geschrieben werden.
6. Legen Sie auf der Seite „Installationsort“ fest, von wo aus die Benutzer installieren. Dass dieser Ort vom Ausgabeort aus Schritt 5 abweichen kann, ist der Punkt, an dem man zuerst stolpert. Wählen Sie zwischen Website, UNC-Freigabe oder CD / DVD / USB.
7. Entscheiden Sie auf der Seite „Einstellungen“, ob die Offline-Nutzung erlaubt ist. Mit Offline-Nutzung erscheint die App im Startmenü und aktualisiert sich automatisch, sobald eine neue Version veröffentlicht wird. Standardmäßig ist die Update-Quelle identisch mit dem Installationsort. Soll eine andere Quelle für Updates verwendet werden, legen Sie dies über die Update-Einstellungen auf dieser Seite fest. Der hier angegebene Ort wird zum deploymentProvider aus 9.6.
8. Über die Links am oberen Rand derselben Seite „Einstellungen“ lassen sich die in die Verteilung einzuschließenden Dateien (Application Files), zu installierende Voraussetzungspakete (Prerequisites) und weitere Optionen festlegen. Auch die Veröffentlichungsversion und ob sie bei jeder Veröffentlichung automatisch erhöht wird, finden Sie hier.
9. Legen Sie auf der Seite „Manifest signieren“ fest, ob die Manifeste signiert werden und welches Zertifikat dabei verwendet wird. Dies knüpft an 9.5 an.
10. Wählen Sie auf der Seite „Konfiguration“ die Build-Konfiguration, ob framework-abhängig oder eigenständig (self-contained) bereitgestellt wird, sowie die Ziel-Runtime-Kennung.
11. Speichern Sie das Profil mit „Fertig stellen“ und drücken Sie auf der Seite „Übersicht“ auf „Veröffentlichen“, um Build und Veröffentlichung auszuführen. Ab dem zweiten Mal genügt auf dieser Seite ein Klick auf „Veröffentlichen“.

In der Praxis lohnt es sich, vorab diese zwei Punkte zu kennen.

• Die Veröffentlichungsversion ist je ClickOnce-Profil unabhängig. Trennen Sie Profile für Test und Produktion, müssen Sie die jeweiligen Versionsnummern bewusst verwalten.
• Das Publish Tool erzeugt ein Veröffentlichungsprofil namens .pubxml. Beim Bauen über die Kommandozeile mit MSBuild geben Sie diese .pubxml an. Das ist der Einstiegspunkt, wenn Sie es in CI einbinden.

6.5 Auch die Übernahme von Einstellungen ist relativ unkompliziert

Wird der Standard-Einstellungsanbieter der Anwendung verwendet, besitzt ClickOnce einen Mechanismus, der beim Update die Einstellungen der vorherigen Version in die neue Version übernimmt (merged).

Das gilt allerdings nur unter der Annahme des Standard-Einstellungsanbieters. Bei eigener Einstellungsspeicherung, eigenen Providern oder geänderten Speicherorten funktioniert das naturgemäß nicht mehr ohne Weiteres.

7. Wo es passt

ClickOnce eignet sich besonders für Projekte wie die folgenden.

Konkrete Beispiele mit guter praktischer Passung sind etwa:

• Interne Anwendungen zur Dateneingabe
• Desktop-Tools für Angebote, Bestellungen, Lagerbestand und Ähnliches
• Hilfsanwendungen zur Gerätekonfiguration
• Interne Clients für Niederlassungen, Werke und Backoffice
• Apps, die zwar Updates wollen, aber keinen dedizierten Updater rechtfertigen

Bei solchen Apps ist es selbst der Wert, Verteilung und Updates einfach zu halten. ClickOnce erfüllt diesen Wert direkt.

Entscheidungsbaum für die Eignung

flowchart TD
    S["Anforderungen ordnen"]
    Q1{"Ist es eine .NET-Desktopanwendung<br/>wie WinForms / WPF?"}
    Q2{"Reicht per-user-Verteilung aus?"}
    Q3{"Soll an Standardbenutzer installiert werden?"}
    Q4{"Lässt sich über Web / Dateifreigabe verteilen?"}
    Q5{"Muss die Update-UX nicht übermäßig ausgearbeitet werden?"}
    G["ClickOnce ist eine sehr starke Option"]
    O["Andere Verfahren vergleichen"]

    S --> Q1
    Q1 -- Nein --> O
    Q1 -- Ja --> Q2
    Q2 -- Nein --> O
    Q2 -- Ja --> Q3
    Q3 -- Nein --> O
    Q3 -- Ja --> Q4
    Q4 -- Nein --> O
    Q4 -- Ja --> Q5
    Q5 -- Ja --> G
    Q5 -- Nein --> O

8. Wo es nicht passt

Andererseits sind auch die Fälle klar erkennbar, in denen man ClickOnce besser nicht erzwingt.

8.1 Eine machine-wide-Installation wird benötigt

ClickOnce basiert grundsätzlich auf per-user.

• Für alle Benutzer gemeinsam installieren
• Unter der Annahme von Program Files installieren
• Geräteweit installieren und verwalten

Für diese Fälle sind MSI und Ähnliches naheliegender als ClickOnce.

8.2 Windows-Dienst / Treiber / Shell-Extension / umfangreiche COM-Registrierung

Das sind Themen, bei denen tief in das OS eingegriffen wird.

• Windows-Dienst
• Treiber
• In-Process-Shell-Extension
• Konfigurationen, die systematische COM-Registrierung voraussetzen

Sobald das ins Spiel kommt, verlässt man das „leicht verteilen“-Weltbild von ClickOnce.

8.3 package identity wird benötigt

Einer der Gründe, sich für MSIX zu entscheiden, ist die Anforderung, package identity zu erhalten.

ClickOnce geht nicht in diese Richtung. Wenn Sie modern packaging oder Windows-Funktionen benötigen, die package identity voraussetzen, sollten Sie MSIX bevorzugen.

8.4 Update-UX und Verteilungskanäle sollen als Produkt selbst gesteuert werden

Sobald Sie zum Beispiel

• Stable- / Beta- / Preview-Kanäle,
• gestaffelte Verteilung,
• die Anpassung der Rollout-Rate anhand von Telemetriedaten,
• feingranulare Kontrolle über Hintergrund-Downloads,
• eine eigene Rollback-Strategie oder
• einen komplexen Lebenszyklus des Updaters selbst

benötigen, reicht das built-in Update von ClickOnce nicht mehr aus.

8.5 Tools, bei denen „nur hinstellen“ genügt

Umgekehrt gibt es auch Fälle, in denen es noch einfacher sein darf.

• Das bloße Ablegen des Ordners genügt
• Auch ein manueller Austausch als Update reicht
• Die Übergabe erfolgt per USB
• In einer geschlossenen Umgebung hat Einfachheit oberste Priorität

In diesen Fällen kann eine xcopy-Verteilung mit weniger Reibung verbunden sein.

Welche Anforderungen zu einem anderen Verfahren führen

flowchart LR
    A1["Installation für alle Benutzer"] --> B1["MSI / teils MSIX"]
    A2["Dienst / Treiber / Shell-Extension / umfangreiches COM"] --> B2["MSI / dedizierter Installer"]
    A3["package identity erforderlich"] --> B3["MSIX"]
    A4["Gestaffelte Verteilung / Kanäle / eigene UX"] --> B4["Eigener Updater"]
    A5["Nur Hinstellen genügt"] --> B5["xcopy"]

ClickOnce ist weder nach oben noch nach unten allmächtig, dafür aber ein Verfahren, das bei Projekten mit genau der richtigen Komplexität stark ist.

9. Häufige Stolperfallen in der Praxis

ClickOnce ist praktisch, führt bei unbedachtem Einstieg aber zu kleinen Stolperfallen. Besonders die folgenden Punkte lohnt es sich, vorab zu kennen.

9.1 Nicht wie einen „gewöhnlichen Installer“ betrachten

ClickOnce ist kein Modell, bei dem an einem festen Installationsort in einer für Menschen direkt verwaltbaren Form abgelegt wird.

Die tatsächlichen Dateien landen in dem von ClickOnce verwalteten Cache und werden je Version getrennt. Deshalb passt es nicht gut zu

• einem Betrieb, der einen festen EXE-Pfad voraussetzt,
• einem Betrieb, bei dem manuell direkt überschrieben wird, oder
• einem Betrieb, bei dem Menschen den Ort der tatsächlichen Dateien kontrollieren.

ClickOnce ist kein Verfahren, bei dem Menschen die Dateiplatzierung verwalten, sondern eines, bei dem der Verteilungszustand über Manifeste verwaltet wird.

9.2 Viele ältere ClickOnce-Artikel setzen .NET Framework voraus

Hier ist Vorsicht geboten.

Auch heute noch finden sich in den oberen Suchergebnissen viele ClickOnce-Artikel aus der Zeit des .NET Framework. Beim aktuellen .NET liegen die Dinge jedoch etwas anders.

• Unter .NET Core 3.1 / .NET 5 / .NET 6 lässt sich die ApplicationDeployment-API nicht unverändert verwenden
• Ab .NET 7 lassen sich manche Bereitstellungseigenschaften über Umgebungsvariablen lesen
• Für die manuelle Bearbeitung von Manifesten wird dotnet-mage.exe vorausgesetzt
• Auch auf Seiten von Visual Studio gelten Anleitungen, die den alten Publish Wizard voraussetzen, teils nicht mehr unverändert

Selbst wenn Sie meinen, „ClickOnce zu kennen“, ist es sicherer, nicht allein aus alter Erinnerung heraus zu implementieren.

9.3 Voraussetzungen getrennt betrachten

ClickOnce selbst ist ein Verteilungsmodell, aber damit die App läuft, können Voraussetzungen nötig sein.

• Die unterstützte Runtime
• Zusätzliche redistributable Komponenten
• Weitere Abhängigkeiten

Hier zahlt sich eine Bootstrapper-Konfiguration mit setup.exe aus. Bleibt das dagegen unklar geregelt, kommt es zu „mit ClickOnce verteilt, aber es läuft nicht“.

9.4 Die Übernahme von Einstellungen hängt davon ab, „was wie gespeichert wird“

Mit dem Standard-Einstellungsanbieter ist die Übernahme der Einstellungen beim Update relativ unkompliziert. Bei

• einem eigenen Einstellungsanbieter,
• der Annahme von Roaming,
• einem selbst geänderten Speicherort für Einstellungen oder
• stark veränderter Einstellungsstruktur zwischen Versionen

funktioniert das naturgemäß nicht mehr ohne Weiteres.

9.5 Signierung und Update-Pfad nicht auf die leichte Schulter nehmen

ClickOnce besitzt einen Mechanismus für Verteilung und Updates, aber das lässt die Verantwortung für Sicherheit nicht verschwinden.

Besonders im Produktivbetrieb sollten Sie vorab klären:

• Wie das Signaturzertifikat verwaltet wird
• Wie der Herausgebername angezeigt wird
• Wie die Update-Quelle verwaltet wird
• Wie die Selbstsignierung für Tests von der Produktionssignierung getrennt wird

flowchart TD
    Cert["Code-Signing-Zertifikat"]
    AppMan["Anwendungsmanifest"]
    DepMan["Bereitstellungsmanifest"]
    Verify["Verifikation auf Client-Seite"]
    Run["Update / Ausführung"]
    Tamper["Manipulation des Manifests"]
    Stop["Bei Verifikationsfehler stoppen"]

    Cert --> AppMan
    Cert --> DepMan
    AppMan --> Verify
    DepMan --> Verify
    Verify --> Run
    Tamper -. Verifikation fehlgeschlagen .-> Stop

„Es gibt Auto-Update“ bedeutet nicht automatisch „es ist sicher“ – was Sie vertrauen und wie dieses Vertrauen erhalten wird, muss separat durchdacht werden.

9.6 Beim Verschieben des Bereitstellungsorts deploymentProvider überprüfen

Das ist unscheinbar, sorgt in der Praxis aber für erhebliche Probleme.

Eine bereits installierte ClickOnce-App sucht Updates an dem Ort, auf den deploymentProvider im Bereitstellungsmanifest verweist. Das heißt: Auch wenn Sie den gesamten Veröffentlichungsordner komplett an eine andere URL oder Freigabe kopieren, kann es passieren, dass der Client weiterhin den ursprünglichen Ort ansieht, solange deploymentProvider nicht aktualisiert wurde.

Und ändern Sie ein Manifest von Hand, ist eine erneute Signierung nötig.

Der Betriebsablauf von der Veröffentlichung bis zur Update-Übernahme

flowchart TD
    Build["Build"]
    AppManifest["Neues Anwendungsmanifest erzeugen"]
    SignApp["Anwendungsmanifest signieren"]
    UpdateDep["Bereitstellungsmanifest auf neue Version aktualisieren"]
    SignDep["Bereitstellungsmanifest signieren"]
    Publish["Am Veröffentlichungsort ablegen"]
    Client["Client erkennt Update"]

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

Letztlich ist beim Betrieb von ClickOnce weniger entscheidend, ob die Dateien abgelegt wurden, sondern vielmehr, ob Manifeste und Signaturen konsistent sind.

10. Zusammenfassung

Kurz gesagt ist ClickOnce

ein Mechanismus, um .NET-Windows-Desktopanwendungen einfach per-user zu verteilen und dabei auch Updates kostengünstig abzudecken.

Seine Stärken liegen hauptsächlich in folgenden Punkten.

• Leicht an Standardbenutzer zu verteilen
• Ein built-in Update-Modell
• Leichte Updates nur der geänderten Teile
• Leichte Trennung von App und Version
• Leicht aus Visual Studio zu veröffentlichen
• Gute Passung zu internen Businessanwendungen

Allerdings ist es nicht allmächtig.

• machine-wide-Installation
• Dienst / Treiber / Shell-Extension
• umfangreiche COM-Registrierung
• package identity
• eigene Kanäle oder gestaffelte Verteilung
• die Ausarbeitung der Update-UX als Produktwert

Bei solchen Anforderungen sollten Sie nicht von ClickOnce, sondern von MSI / MSIX / einem eigenen Updater aus denken.

ClickOnce ist kein einfacher Installer, der für alles passt, aber bei passenden Projekten auch heute noch ziemlich stark.

Wenn Sie

• eine .NET-Windows-Businessanwendung verteilen möchten,
• bei der eine Installation je Benutzer ausreicht,
• die an Standardbenutzer gehen soll und
• bei der Sie Updates nicht selbst betreiben möchten,

gehört ClickOnce zu den starken Kandidaten.

11. Verwandte Artikel

• Wie man das Verteilungsverfahren für Windows-Apps wählt - MSI/MSIX/ClickOnce/xcopy/eigenes Update
• Sicherheitsdesign für Auto-Updates - Warum HTTPS allein nicht reicht
• Wann werden unter Windows Administratorrechte benötigt - UAC, geschützte Bereiche und wie man es im Design erkennt

Verwandte Themen

Themenseiten, die diesem Thema nahestehen. Ausgehend von diesem Artikel geht es weiter zu verwandten Services und anderen Artikeln.

Windows-Technikthemen

Ein Einstiegspunkt, der technische Themen zu Windows-Entwicklung, Fehleruntersuchung und Weiternutzung bestehender Assets bündelt.

Services, die zu diesem Thema passen

Dieser Artikel führt zu den folgenden Servicepages. Steigen Sie über den passendsten Einstieg ein.

Windows-Anwendungsentwicklung

Bei internen Businessanwendungen, Gerätekonfigurationstools oder der Überarbeitung bestehender Software hängt es stark von einer Klärung vor der Implementierung ab, welches von ClickOnce / MSI / MSIX / xcopy am wenigsten Reibung erzeugt.

Service ansehen Kontakt

Technische Beratung & Design-Review

Fragen wie „Reicht ClickOnce aus?“, „Sollten wir auf MSIX oder MSI setzen?“ oder „Reicht ein built-in Auto-Update, oder betreiben wir es selbst?“ lassen sich leichter entscheiden, wenn sie vor der Implementierung geklärt werden.

Service ansehen Kontakt

Autorenprofil

Go Komura

Geschäftsführer, KomuraSoft LLC

Mit Schwerpunkt auf Windows-Softwareentwicklung, technischer Beratung und Fehlersuche liegen die Stärken bei Projekten mit bestehenden Altbeständen sowie bei der Untersuchung von Störungen, deren Ursache schwer erkennbar ist.

Profil ansehen Kontakt

12. Referenzlinks

• 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

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist ClickOnce?

Es ist eine Verteilungstechnologie, um .NET-Windows-Desktopanwendungen einfach je Benutzer zu verteilen und dabei auch automatische Updates mit abzudecken. Offiziell wird es als Verteilungstechnologie für Windows-basierte Apps beschrieben, die sich mit minimaler Benutzerinteraktion installieren und ausführen lassen und die sich selbst aktualisieren können. Tatsächlich handelt es sich um ein Verteilungsmodell, das Verteilung, Updates und Cache-Verwaltung gebündelt um Manifeste herum organisiert; die App wird dabei in einem sicheren, benutzerbezogenen Cache-Bereich gehalten und je App, je Benutzer und je Version getrennt.

Lässt sich ClickOnce auch künftig verwenden? Ist es nicht veraltet?

Auch beim aktuellen .NET bleibt ClickOnce eine normale Option. In Visual Studio wird für .NET Core 3.1 und .NET 5 und später das Publish Tool verwendet; wer Manifeste manuell bearbeitet, nutzt dotnet-mage.exe. Zu beachten ist allerdings, dass sich die Lage gegenüber der Zeit des .NET Framework verändert hat: Unter .NET Core 3.1 / .NET 5 / .NET 6 lässt sich die ApplicationDeployment-API nicht unverändert verwenden, und ab .NET 7 werden manche Bereitstellungseigenschaften über Umgebungsvariablen gelesen. Es ist sicherer, nicht allein aus der Erinnerung an alte Artikel heraus zu implementieren.

Für welche Apps eignet sich ClickOnce?

Es eignet sich besonders für interne WinForms- / WPF-Businessanwendungen, bei denen an Standardbenutzer ohne Administratorrechte verteilt werden soll, per-user-Verteilung ausreicht und Updates built-in gewünscht sind. Auch als Verteilungsweg genügen Website oder Dateifreigabe. Umgekehrt eignet es sich nicht für Anforderungen wie eine machine-wide-Installation für alle Benutzer, Windows-Dienste, Treiber, Shell-Extensions, umfangreiche COM-Registrierung, package identity oder die eigene Steuerung von Update-Kanälen und gestaffelter Verteilung – hier sollte man von MSI / MSIX / einem eigenen Updater aus denken.

Wie funktioniert das automatische Update von ClickOnce?

Die Update-Entscheidung beginnt beim Bereitstellungsmanifest (.application). Die App liest das Bereitstellungsmanifest und prüft, ob eine neuere Version existiert, ob das Update verpflichtend ist und von wo sie geholt wird. Beim Update vermeidet file patching überflüssige erneute Downloads, indem das neue Anwendungsmanifest mit der aktuellen Version verglichen wird und nur die geänderten Dateien geholt werden. Im ClickOnce-Cache werden aktuelle und vorherige Version getrennt aufbewahrt, nach dem Prinzip, die neue Version zunächst korrekt zu materialisieren und dann umzuschalten. Ohne Netzwerkverbindung wird die App ohne Update-Prüfung einfach direkt ausgeführt.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.