Windows-App-Verteilung wählen – MSI/MSIX/ClickOnce/xcopy/eigener Updater

Excel-Entscheidungsarbeitsblatt mit japanischem und englischem Blatt herunterladen

Wenn es darum geht, die Verteilungsmethode für eine Windows-App festzulegen, beginnt man das Gespräch gern mit „was ist am neuesten“ oder „was ist am einfachsten“. In der Praxis zählen aber andere Achsen wirklich.

• Wollen Sie per-user einführen oder maschinenweit?
• Wollen Sie das Update einer Verteilungsplattform überlassen oder selbst tragen?
• Gibt es OS-Integration wie Dienste / Treiber / Shell-Erweiterungen / COM-Registrierung?
• Muss die Lösung geschlossene Netzwerke, Offline-Betrieb oder USB-Verteilung aushalten?
• Brauchen Sie package identity, oder wollen Sie als reines, unrestricted Win32 laufen?

Die Wahl der Verteilungsmethode ist keine Frage des Installer-Geschmacks, sondern eine Wahl darüber, wie tief Sie ins OS eingreifen und wer die Update-Verantwortung trägt.

Dieser Artikel richtet sich an Entwickler, die eine Windows-Desktop-App bauen und die Verteilungsmethode gerade festlegen oder ihre bestehende Methode überdenken wollen, sowie an die IT-Verantwortlichen, die den Betrieb übernehmen. Eine bestimmte Sprache oder ein bestimmtes Framework wird nicht vorausgesetzt. Da in diesem Bereich viele Begriffe im englischen Original gebräuchlich sind, sind sie in Abschnitt 1.1 zusammengefasst. Der Inhalt des Arbeitsblatts oben ist in Abschnitt 1.2 zusammengefasst.

1. Zuerst das Fazit

Ziemlich grob, aber praxistauglich zusammengefasst:

• Führen Sie maschinenweit ein, registrieren Sie einen Dienst oder COM, oder müssen Voraussetzungen installiert werden, denken Sie zuerst von MSI aus
• Setzen Sie Windows 10/11 voraus und wollen clean install / clean uninstall, häufige Updates und package identity, ist MSIX stark
• Wollen Sie eine .NET-Business-App fürs eigene Unternehmen per-user einfach verteilen und automatisch aktualisieren, ist ClickOnce nach wie vor sehr stark
• Priorisieren Sie Tools, die nur abgelegt werden müssen, geschlossene Netzwerke, USB-Verteilung, keine Administratorrechte, ist xcopy am naheliegendsten
• Wollen Sie Update-UX, Kanäle, gestufte Verteilung, Telemetrie und Wiederherstellungsstrategie selbst in der Hand halten, ist das ein eigener Updater
• Brauchen Sie einen Treiber, ist es sicherer, nicht von Anfang an vorrangig auf MSIX zu setzen
• Brauchen Sie eine in-process-Shell-Erweiterung des Explorers, prüfen Sie zuerst, was MSIX abdeckt und welche OS-Bedingungen gelten

Grob zusammengefasst:

1. Viel OS-Registrierung → eher MSI
2. package identity und modernes Packaging gewünscht → MSIX
3. Einfache per-user-Verteilung und eingebaute Updates gewünscht → ClickOnce
4. Reine Ablage-Verteilung hat oberste Priorität → xcopy
5. Bereitschaft, die Update-Infrastruktur selbst zu entwerfen und zu betreiben → eigener Updater

1.1 Begriffe, die im Artikel vorkommen

Rund um die Verteilung sind viele Begriffe im englischen Original gebräuchlich, deshalb vorab eine Übersicht.

1.2 Was im Arbeitsblatt am Anfang steckt

Das Excel-Arbeitsblatt am Anfang dient dazu, die Überlegungen dieses Artikels auf Ihr eigenes Projekt anzuwenden und festzuhalten. Es gibt eine japanische und eine englische Version, jeweils mit zwei Blättern.

Das Planner-Blatt ist in drei Blöcke gegliedert.

1. Eingabeblatt: Füllen Sie die folgenden 7 Punkte aus, damit ein erster Kandidat samt Begründung festgehalten wird
   • Verteilungsumfang … per-user / per-machine / beides / noch offen
   • OS-Integrationselemente … keine / Dienst / Treiber / Shell-Erweiterung / COM-Registrierung / mehrere
   • package identity … nötig / nicht nötig / nicht einschätzbar
   • Anforderung an Standardbenutzer-Einführung … zwingend / nicht nötig / kommt darauf an
   • Update-Frequenz … manuell oder selten / monatlich / wöchentlich / öfter
   • Zielumgebung … geschlossenes Netzwerk / Offline / verwaltetes, aktuelles Windows / gemischte Windows-Generationen / USB / Einsatzort
   • Notiz zum App-Typ … interne .NET-Desktop-App / kommerzielles Produkt / Hilfsprogramm / gemischt
2. Kandidaten unterscheiden: Für jede der 5 Methoden, worauf zuerst stark zu achten ist und was sich leicht zuerst ausschließen lässt
3. Ablauf der Entscheidung: In welcher Reihenfolge die obigen Punkte betrachtet werden und zu welcher Methode das jeweils tendenziell führt

Das Reference-Blatt enthält unverändert die Entscheidungstabelle aus Kapitel 3 und die Vergleichstabelle aus Kapitel 4 dieses Artikels.

Es handelt sich also um die Kapitel 3, 4 und 7 dieses Artikels in einer Form, die sich projektweise ausfüllen lässt. Wenn das Lesen allein schon zur Entscheidung reicht, brauchen Sie den Download nicht. Nutzen Sie es, wenn Sie mehrere Projekte vergleichen oder die Entscheidungsgrundlage intern dokumentieren wollen.

2. Die fünf Optionen stehen nicht auf demselben Spielfeld

Das ist ziemlich wichtig.

MSI / MSIX / ClickOnce / xcopy betreffen vor allem wie eingeführt wird. Ein eigener Updater betrifft dagegen vor allem wer die Update-Verantwortung trägt.

In der Praxis lässt sich das leichter in zwei Schichten denken.

Als Diagramm sieht das so aus. Die gepunkteten Linien zeigen, „welches Update-Mittel bei dieser Einführungsmethode naheliegend verbunden ist“.

flowchart TB
    APP["Zu verteilende Windows-App"] --> Q1["Zuerst: Wie wird eingeführt?<br/>Schicht Erstinstallation"]
    APP --> Q2["Dann: Wer trägt die Update-Verantwortung?<br/>Schicht laufende Updates"]

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

    Q2 --> AI["MSIX App Installer"]
    Q2 --> COU["Eingebautes Update von ClickOnce"]
    Q2 --> MAN["Manueller Austausch"]
    Q2 --> OWN["Eigener Updater"]

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

Bei ClickOnce und MSIX ist mit der Entscheidung für die obere Schicht auch die untere Schicht so gut wie festgelegt. Bei MSI und xcopy muss die untere Schicht dagegen separat entschieden werden. Gerade bei diesen beiden Methoden bleibt „wie machen wir das Update“ leicht in der Luft hängen.

Deshalb ist es weniger irreführend, sich zu merken, dass ein eigener Updater nicht die erste Wahl ist, sondern etwas, das man zusätzlich wählt, wenn die vorhandene Verteilungsmethode die Update-Anforderungen nicht abdeckt.

3. Die Entscheidungstabelle auf einen Blick

Zuerst die am einfachsten nutzbare Entscheidungstabelle.

Das Wichtigste an dieser Tabelle ist, nicht allein wegen „es gibt Updates“ zum eigenen Updater zu springen.

4. Vergleich nach Kriterien

In dieser Tabelle geht es nicht darum, was am stärksten ist, sondern darum, was am wenigsten Reibung verursacht.

5. Für welche Projekte sich welche Methode eignet

5.1 MSI

MSI ist der Ausgangspunkt, wenn Sie eine traditionelle Windows-Desktop-App sauber installieren, deinstallieren und reparieren wollen.

Besonders gut geeignet ist es für Projekte wie diese.

• Business-Apps für alle Benutzer
• Apps mit Windows-Dienst
• Apps mit COM-Registrierung, Dateizuordnung oder maschinenweiten Einstellungen
• Produkte, für die bereits ein bestehender Installer-Betrieb existiert

Die Stärke von MSI ist, dass sich „wie die App ins OS eingeführt wurde“ im Windows-eigenen Stil ausdrücken lässt.

Die Schwächen sind aber ebenso klar.

• Das Authoring ist unauffällig schwierig
• Wird Upgrade / Patch nachlässig entworfen, rächt sich das später leicht
• Je mehr custom actions hinzukommen, desto zerbrechlicher wird es
• Bei Produkten mit hoher Update-Frequenz wird die Update-UX leicht schwerfällig

5.2 MSIX

MSIX ist die Wahl, wenn Sie modernes Packaging sowie sauberes Update / Uninstall wollen. Auch wenn Sie Windows-Funktionen nutzen wollen, die package identity voraussetzen, gewinnt es deutlich an Bedeutung.

Geeignet ist es etwa hierfür.

• Desktop-Apps, die Windows 10/11 voraussetzen können
• Business-Apps mit eher hoher Update-Frequenz
• Apps, die Windows-Funktionen nutzen wollen, für die package identity wirkt
• Projekte, die sich an Intune oder App Installer orientieren wollen

Die Stärke von MSIX ist die Sauberkeit von Update und Deinstallation.

Allerdings passt nicht alles hinein. Besonders diese 4 Punkte sollten vorab geprüft werden.

• in-process-Shell-Erweiterung (MSIX kann ab Windows 11 21H2 legacy Kontextmenü-Handler und Ähnliches registrieren, aber Manifest-Deklaration und Ziel-OS müssen geprüft werden)
• Treiber
• Alte, unrestricted Win32-Annahmen
• Konfigurationen, bei denen package identity nicht gewünscht ist

Für diese 4 Punkte gibt es jeweils unterschiedliche Stellen, an denen man nachschauen kann. Statt bei „MSIX soll wohl nicht gehen“ stehenzubleiben, lohnt es sich, vorab festzulegen, welche Unterlage die Frage klärt.

Die Links dazu stehen alle in den Quellen in Kapitel 9. Schauen Sie beim Entscheiden nicht nur, „ob es unterstützt wird“, sondern „ab welcher Version, mit welcher Deklaration es unterstützt wird“. Wird das nicht inklusive der OS-Versionsbedingung geklärt, zeigt sich später, dass es auf dem Testrechner lief, aber auf dem alten Windows im Einsatz nicht installiert werden konnte.

5.3 ClickOnce

ClickOnce ist nach wie vor sehr stark, wenn Sie eine interne .NET-Desktop-App per-user, schnell und mit Update betreiben wollen.

Geeignet ist es für solche Szenarien.

• Interne Business-Apps
• Einführung mit Standardbenutzerrechten gewünscht
• Verteilung pro Benutzer reicht aus
• Die Update-UX soll nicht groß selbst gebaut werden

Umgekehrt ist es sicherer, nicht zu erwarten, dass es tief ins OS eingreifende Produkte abdeckt oder die Rolle eines Installers übernimmt, der mehrere Voraussetzungen bündelt.

5.4 xcopy

xcopy ist deploy, nicht install. Es gibt keine Registry-Registrierung, keine Reparaturfunktion, keine package identity. Dafür ist es, wenn reines Ablegen genügt, an Einfachheit kaum zu übertreffen.

Seine Stärke zeigt sich bei Werkzeugen wie diesen.

• Diagnosewerkzeuge
• Werkzeuge zur Gerätekonfiguration
• Werkzeuge zur Log-Erfassung
• Hilfsprogramme, die per USB vor Ort übergeben werden
• Fälle, in denen mehrere Versionen side-by-side koexistieren sollen

Die Stärke von xcopy ist, dass sich die Art des Scheiterns leicht nachvollziehen lässt. Den ganzen Ordner austauschen, und wenn man zurückwill, zur vorherigen Version zurückkehren – dieser Betrieb ist einfach.

Selbstverständlich hat es aber auch Schwächen.

• Startmenü / ARP / Reparatur
• Dateizuordnung / Dienst / Shell-Erweiterung / Treiber
• Eingebautes Update

5.5 Eigener Updater

Ein eigener Updater ist eher eine Wahl der Verantwortung als eine Wahl der Freiheit.

Er lohnt sich, wenn solche Anforderungen bestehen.

• Hohe Update-Frequenz
• Sie wollen Kanäle wie stable / beta / preview haben
• Sie wollen gestufte Verteilung und Rollout-Quote steuern
• Sie wollen Hintergrund-Download, Benachrichtigungen und Wartungsfenster fein steuern
• Sie wollen Update-Telemetrie und Crash Recovery selbst betreiben

Die Stärken sind groß, aber der Preis ist es auch.

• Signaturprüfung
• Verteilungs-Manifest
• Wiederholungsversuch / Fortsetzung
• Proxy- / Firewall- / Unterstützung geschlossener Netzwerke
• Rollback
• Wiederherstellung nach fehlgeschlagenem Update
• Aktualisierung des Updaters selbst

Mit anderen Worten: Was zunimmt, ist nicht die Freiheit, sondern die Verantwortung.

5.6 Was als Nächstes zu klären ist, nachdem die Methode feststeht

Auch wenn Sie sich für „wir machen es mit MSI“ entschieden haben, kommen Sie ins Stocken, wenn unklar ist, was als Nächstes zu klären ist. Hier eine Übersicht typischer Einstiegspunkte. Keiner davon bedeutet „nutzen Sie genau das“ – es sind Dinge, deren Namen zu kennen sich lohnt, sobald Sie sich für diese Methode entschieden haben.

Zu beachten ist hier, dass die Wahl eines Werkzeugs und die Wahl einer Methode zwei verschiedene Dinge sind. Inno Setup etwa ist einfach zu handhaben, erzeugt aber kein MSI und passt daher nicht zu einem Betrieb, der den Windows Installer voraussetzt – etwa die Softwareverteilung über Gruppenrichtlinien oder die Reparatur über msiexec. Wenn der Grund, in Abschnitt 5.1 MSI zu wählen, genau dort liegt, muss auch das Werkzeug entsprechend gewählt werden.

6. Häufige Streitpunkte

6.1 Wird package identity benötigt?

Wenn Sie eine Windows-Funktion wollen, die package identity voraussetzt, steigt der Wert von MSIX schlagartig.

Wollen Sie umgekehrt

• unrestricted Dateisystemzugriff
• unrestricted Registry-Zugriff
• Freiheit bei Elevation / Prozessmodell
• alte Win32-Annahmen unverändert beibehalten

dann liegt eher eine unpackaged-orientierte Methode nahe.

6.2 Gibt es Dienst / Treiber / Shell-Erweiterung?

Diese drei machen die Verteilungsmethode auf einen Schlag schwerer.

• Treiber: schlecht geeignet für MSIX
• in-process-Shell-Erweiterung: schlecht geeignet für MSIX
• Windows-Dienst: bei MSI naheliegend, bei MSIX unter Bedingungen eine Vergleichsoption

Je tiefer die OS-gekoppelten Elemente sind, desto mehr rückt statt „wie einfach die Verteilung aussieht“ die Frage in den Vordergrund, ob sich korrekt installieren, aktualisieren und entfernen lässt.

6.3 per-user oder per-machine?

Bleibt das unklar, gibt es später garantiert Streit.

• Tendenz zu per-user
  • ClickOnce
  • xcopy
  • Teile von MSIX
• Tendenz zu per-machine
  • MSI
  • MSIX, sofern die Bedingungen passen

„Wir wollen ohne Administratorrechte einführen“ und „alle Benutzer sollen es vom selben Ort aus nutzen“ sind nicht dasselbe.

6.4 Update-Frequenz und Betriebsverantwortung

Grob nach Update-Frequenz betrachtet, sieht das so aus.

• Quartalsweise bis monatliche Updates: MSI reicht völlig
• Monatlich bis wöchentliche Updates: MSIX / ClickOnce sind deutlich bequemer
• Wöchentlich bis tägliche Updates: es gibt Gründe, einen eigenen Updater in Betracht zu ziehen
• Update darf manuell erfolgen / die verteilende Seite steuert es: xcopy reicht aus

Die Verteilungsmethode ist ebenso sehr Betriebsdesign wie Technologiewahl.

6.5 Geschlossene Netzwerke und Offline-Verteilung

In geschlossenen Netzwerken gewinnt oft Einfachheit gegenüber elegantem Auto-Update.

• xcopy ist stark
• MSI ist auch stark
• ClickOnce funktioniert auch über Dateifreigaben oder Wechseldatenträger
• Auch MSIX lässt sich je nach Einsatz von App Installer betreiben

Aktualisieren Sie in einem geschlossenen Netzwerk aber häufig, gerät der Betrieb leicht ins Wanken, egal welche Methode Sie wählen, wenn nicht auch geklärt ist, „wer, wo, die neue Version ablegt und wie die alte Version aufbewahrt wird“.

7. Die abschließenden 6 Fragen, wenn Sie unschlüssig sind

1. Reicht es, wenn die App nur für den aktuellen Benutzer gilt, oder muss sie maschinenweit installiert werden?
2. Gibt es Dienst / Treiber / Shell-Erweiterung / COM-Registrierung?
3. Werden Windows-Funktionen genutzt, die package identity voraussetzen?
4. Soll die Einführung nur mit Standardbenutzerrechten möglich sein?
5. Ist die Update-Frequenz monatlich, wöchentlich oder höher?
6. Ist die Zielumgebung ein geschlossenes Netzwerk, und sind die OS-Versionen einheitlich?

Allein das Beantworten dieser 6 Fragen zeigt meist schon, wo es hinläuft.

• Ist 2 „ja“ → zuerst von MSI aus denken
• Ist 3 „ja“ → MSIX vorrangig prüfen
• Ist 1 „aktueller Benutzer“, 4 „ja“ und handelt es sich um eine .NET-Desktop-App → ClickOnce ist ein starker Kandidat
• Ist 4 „ja“, 2 „nein“ und reiner Ablage-Betrieb genügt → xcopy ist ein starker Kandidat
• Ist 5 hoch und wollen Sie die Update-UX als Produktwert selbst in der Hand halten → einen eigenen Updater in die Vergleichsliste aufnehmen

8. Zusammenfassung

Die Verteilungsmethode für Windows-Apps lässt sich weitgehend auf diesen einen Satz verdichten:

Wie die Erstinstallation gelingt und wer die Verantwortung für die laufenden Updates trägt, getrennt entscheiden.

Darauf aufbauend die groben praktischen Einschätzungen:

• MSI: traditionelle Desktop-Apps, die tief ins OS eingreifen
• MSIX: Apps, die package identity und modernes Packaging / Update wollen
• ClickOnce: eine per-user-.NET-Business-App einfach verteilen und aktualisieren
• xcopy: selbstständige Tools, bei denen reines Ablegen genügt
• Eigener Updater: Produkte, bei denen die Bereitschaft besteht, das Update selbst zu entwerfen und zu betreiben

Und das Wichtigste ist dies:

• Gibt es Treiber / Shell-Erweiterung / Dienst, entscheidet sich die Verteilungsmethode nicht am äußeren Erscheinungsbild, sondern an der Art der OS-Integration
• Wird package identity benötigt, gewinnt MSIX stark an Bedeutung
• Ein eigener Updater ist das letzte Mittel, nicht die erste Option
• In geschlossenen Netzwerken gewinnt oft Einfachheit gegenüber Cleverness

Sind Sie unschlüssig, bringt es das Gespräch schon deutlich voran, wenn Sie zuerst nur diese drei Punkte festlegen: per-user oder per-machine, was beim OS registriert wird und wie hoch die Update-Frequenz ist.

9. Quellen

• Microsoft Learn, Windows Installer
• Microsoft Learn, What is MSIX?
• Microsoft Learn, Packaging overview for Windows apps
• Microsoft Learn, MSIX features and supported platforms
• Microsoft Learn, Support legacy context menus for packaged apps
• Microsoft Learn, App Installer file overview
• Microsoft Learn, Prepare to package a desktop application
• Microsoft Learn, Know your installer
• Microsoft Learn, Convert an installer that includes services
• Microsoft Learn, ClickOnce deployment and security
• Microsoft Learn, Manage updates for a ClickOnce application
• Microsoft Learn, Choosing a ClickOnce deployment strategy
• Microsoft Learn, ClickOnce cache overview
• Microsoft Learn, Windows App SDK deployment guide for self-contained apps

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 der Unterschied zwischen MSI und MSIX?

MSI ist das traditionelle Windows-Installerformat und passt gut zu per-machine-Einführungen sowie zu Einführungen, die tief ins OS eingreifen, etwa Windows-Dienste, COM-Registrierung oder Shell-Erweiterungen – install, uninstall und repair lassen sich damit im Windows-eigenen Stil abbilden. MSIX ist modernes Packaging, das Windows 10/11 voraussetzt, und punktet mit clean install / clean uninstall, häufigen Updates und package identity. MSIX eignet sich dagegen nicht gut für Treiber, in-process-Shell-Erweiterungen werden erst ab Windows 11 21H2 unter bestimmten Bedingungen unterstützt, und auch für unrestricted-Annahmen im Stil des alten Win32 ist es nicht geeignet. Wer viel beim OS registrieren muss, startet bei MSI; wer package identity und saubere Updates will, startet bei MSIX.

Soll ich MSIX oder ClickOnce wählen?

Wenn Sie eine .NET-Business-App fürs eigene Unternehmen per-user einfach verteilen und automatisch aktualisieren wollen, ist ClickOnce nach wie vor eine sehr starke Wahl. Das eingebaute Update-Modell ist leicht zu nutzen, die Einführung gelingt mit Standardbenutzerrechten, und eine eigene Update-UX muss nicht erst gebaut werden. Wollen Sie dagegen Windows-Funktionen nutzen, die package identity voraussetzen, Wert auf clean install / uninstall legen oder sich an Intune oder App Installer orientieren, ist MSIX die stärkere Option. Beide eignen sich nicht für Produkte, die tief ins OS eingreifen – wenn ein Dienst oder ein Treiber im Spiel ist, denken Sie zuerst von MSI aus.

Kann man ClickOnce heute noch verwenden? Ist es nicht veraltet?

Es lässt sich nach wie vor verwenden und ist in den passenden Szenarien eine ziemlich starke Option. Es eignet sich, wenn Sie eine interne .NET-Desktop-App per-user, mit Standardbenutzerrechten, schnell verteilen und über das eingebaute Update-Modell aktualisieren wollen. Umgekehrt sollten Sie nicht erwarten, dass es die Rolle eines Installers übernimmt, der tief ins OS eingreifende Produkte wie Windows-Dienste, Treiber oder Shell-Erweiterungen abdeckt oder mehrere Voraussetzungen bündelt. Bei einer Update-Frequenz von monatlich bis wöchentlich lassen sich ClickOnce und MSIX ziemlich bequem betreiben.

Wann sollte man einen eigenen Updater in Betracht ziehen?

Ein eigener Updater ist nicht die erste Wahl, sondern etwas, das man zusätzlich wählt, wenn die vorhandene Verteilungsmethode die Update-Anforderungen nicht abdeckt. Er lohnt sich, wenn die Update-Frequenz hoch ist, Sie Kanäle wie stable / beta / preview haben wollen, gestufte Verteilung oder eine Rollout-Quote steuern wollen, oder wenn Sie Update-Telemetrie und Crash Recovery selbst betreiben wollen. Allerdings übernehmen Sie dabei die Verantwortung, Signaturprüfung, Verteilungs-Manifest, Wiederholungsversuche, Rollback, die Wiederherstellung nach fehlgeschlagenen Updates und sogar die Aktualisierung des Updaters selbst zu entwerfen und zu betreiben – es ist also eine Wahl, die nicht mehr Freiheit, sondern mehr Verantwortung mit sich bringt.

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.