Auswählen eines Verteilungspfads für Ihre Windows-App

Wie Sie Ihre Windows-App verteilen, wirkt sich auf Codesignaturkosten, Updatemechanik, Unternehmensverwaltbarkeit und wie einfach Kunden die App auffinden und installieren. In diesem Artikel werden die Wichtigsten Pfade verglichen, die Ihnen dabei helfen, die richtige Wahl zu treffen.

Verteilungspfade auf einen Blick

Microsoft Store (empfohlen)

Die Veröffentlichung im Microsoft Store ist die umfassendste Verteilungslösung für Windows-Apps. Es stehen zwei Übermittlungspfade zur Verfügung:

• MSIX-Übermittlung – empfohlen für neue Apps und WinUI 3-Apps. Microsoft das Paket neu signiert; kein Zertifikatkauf erforderlich. Umfasst vom Store verwaltete Updates, mehrstufige Rollouts und differenzielle Downloads.
• MSI/EXE Installer-Übermittlung – für vorhandene Win32-Apps mit eigenem Installationsprogramm. Publisher sendet eine versionsierte HTTPS-URL an das Installationsprogramm, das im eigenen CDN des publisher gehostet wird. Der Store lädt das Installationsprogramm aus dieser URL als Teil des Store-Installationsablaufs herunter und führt es aus. Publisher muss das Installationsprogramm mit einem Zertifikat signieren, das zu einer Zertifizierungsstelle im Microsoft Trusted Root Program gehört. Updates sind die Verantwortung der App.

Was Sie erhalten (beide Pfade):

• Entdecken Sie durch die Suche im Store und die kuratierten Sammlungen
• UX für vertrauenswürdige Installationen
• Enthalten sind Umsatzverarbeitung, Rückerstattungen und Analysen
• Bereitstellung im Unternehmen über Intune mit Unternehmensportal

Anforderungen:

• MSIX ist das empfohlene Paketformat – WinUI 3-Apps werden standardmäßig verpackt. Win32-Apps mit einem vorhandenen MSI- oder EXE-Installationsprogramm können auch über den MSI/EXE Installer-Pfad eingereicht werden (Hinweis: MSI/EXE-Übermittlungen erfordern eine Zertifikatverkettung zu einer Zertifizierungsstelle im Microsoft Trusted Root Program – selbstsignierte Zertifikate werden nicht akzeptiert; Store-verwaltete Updates sind für diesen Pfad nicht verfügbar).
• Die App muss die Store-Zertifizierungsanforderungen erfüllen: MSIX requirements |
• Entwicklerkonto erforderlich (Partner Center)

Wann Sie dies wählen sollten:

• Ihre App richtet sich allgemein an Verbraucher oder Unternehmensbenutzer.
• Sie möchten die einfachste Verteilungsinfrastruktur
• Sie erstellen eine neue WinUI 3-App (Sie sind bereits verpackt – einfach übermitteln)

Im Microsoft Store veröffentlichen

Progressive Webapp (PWA)

Wenn Ihre App eine Website ist oder in erster Linie auf Webtechnologien basiert, ist eine Progressive Web App der schnellste Weg zum Microsoft Store – es ist kein Kauf von nativen Verpackungstools oder einer Codesignatur erforderlich.

Eine PWA ist eine Web-App, die Browser als eigenständige App installieren können. Sie kann offline ausgeführt werden, Pushbenachrichtigungen senden, im Startmenü und in der Taskleiste angezeigt und über die Microsoft Store verteilt werden. Verwenden Sie PWABuilder , um Ihre Website für die Store-Übermittlung in Minuten zu verpacken.

Was Sie erhalten:

• Store-Verteilung mit kostenloser Codesignatur (Store signiert das Paket)
• Funktioniert auf jedem Gerät mit einem modernen Browser
• Keine manuelle Erstellung von MSIX-, WiX- oder Installationsprogrammen erforderlich – Tools wie PWABuilder generieren das Übermittlungspaket für den Store für Sie.
• Integrierte Updatebereitstellung – Benutzer erhalten immer Ihre neuesten Webinhalte (gehostete Inhaltsupdates ohne erneute Store-Übermittlung)

Anforderungen:

• Die App muss über HTTPS bereitgestellt werden.
• Web-App-Manifest und Service Worker
• Die App muss die Store-Zertifizierungsanforderungen erfüllen.

Limitations:

• Umfassende native Windows-APIs (Dateisystemzugriff, Hardwareintegration über Web-APIs hinaus) sind ohne zusätzliche Überbrückung nicht verfügbar.
• App-Logik wird in einem Webkontext ausgeführt – nicht geeignet für Apps, die systemeigene .NET-, C++- oder WinRT-APIs erfordern

Wann Sie dies wählen sollten:

• Ihre App ist eine Web-App, ein SaaS-Tool oder eine Inhaltswebsite, die Sie installieren möchten.
• Sie möchten den schnellsten Weg zum Store mit minimalen Tools
• Ihre Featureanforderungen werden von modernen Web-APIs erfüllt.

→ Overview der progressiven Web-Apps
Veröffentlichen Sie eine PWA im Microsoft Store mithilfe von PWABuilder

MSIX-Sideloading – Unternehmensinterne LOB-Verteilung

Für interne Branchen-Apps, die über Microsoft Intune oder Konfigurations-Manager auf verwalteten Geräten bereitgestellt werden, ist MSIX Sideloading der empfohlene Pfad.

Was Sie erhalten:

• Stille Installation und Aktualisierung über MDM-Richtlinien
• Integration in die Unternehmensgeräteverwaltung (Intune, ConfigMgr)
• Vollständige Paketidentität und Zugriff auf Windows Features (Benachrichtigungen, Hintergrundaufgaben usw.)

Code-Signierung:

• Verwenden Sie Azure Artifact Signing (vormals Trusted Signing) (~10 USD/Monat) für ein zertifizierungsstellenvertrauenswürdiges Zertifikat oder
• Verwenden eines selbstsignierten Zertifikats, das über Intune-vertrauenswürdige Zertifikatprofile für Endpunkte bereitgestellt wird

Anforderungen:

• Zielgeräte müssen dem Signaturzertifikat vertrauen (entweder über MDM oder Gruppenrichtlinie)
• Querladen muss auf Zielgeräten zulässig sein (standardmäßig auf Windows 10 Version 2004+ und allen Windows 11 Geräten aktiviert)

Wann Sie dies wählen sollten:

• Verteilen einer internen App an unternehmensverwaltete Geräte
• Sie verfügen über ein IT-Team, das die Zertifikatvertrauensstellung über Intune oder Gruppenrichtlinien konfigurieren kann

→ Bereitstellen von MSIX-Apps mit Intune
→ Deploy MSIX-Apps mit Konfigurations-Manager

MSIX Direct Download – ISV und kommerzielle Apps

Für kommerzielle Apps, die direkt von Ihrer Website (nicht über den Store) verkauft werden, können Sie MSIX-Pakete mit einer .appinstaller Datei zur Unterstützung von automatischen Updates verteilen.

Was Sie erhalten:

• Vertraute Installationserfahrung über das App-Installationsprogramm
• Unterstützung für die automatische Aktualisierung über .appinstaller Datei (gehostet auf Ihrem Server)
• Vollständige Paketidentität und Windows Featurezugriff
• Kontrolle über Ihren eigenen Vertriebskanal und Preise

Code-Signierung:

• Ein von einer Zertifizierungsstelle vertrauenswürdiges Code-Signaturzertifikat ist erforderlich — Benutzer können MSIX-Pakete ohne Signatur oder mit selbstsigniertem Zertifikat nur installieren, wenn sie dem Zertifikat manuell vertrauen.
• Azure Artifact Signing (ehemals vertrauenswürdige Signatur) (~10 USD/Monat) ist Microsoft empfohlene Option: Kein Hardwaretoken erforderlich, in CI/CD-Pipelines integriert
• Herkömmliche OV-Zertifikate werden ebenfalls akzeptiert (in der Regel 150–300 US-Dollar/Jahr von einer CA [Certification Authority])

SmartScreen: Neue Zertifikate sammeln im Laufe der Zeit den SmartScreen-Ruf basierend auf der Downloadmenge. Sie können einige SmartScreen-Eingabeaufforderungen für neue Versionen erwarten. Siehe SmartScreen-Reputation für Windows App-Entwickler.

Wann Sie dies wählen sollten:

• Sie sind ein ISV, der Software direkt von Ihrer Website verkauft
• Sie benötigen kontrolle über die UX, Preise oder Lizenzierung des Installers, die der Store nicht unterstützt.
• Ihre Kunden sind Unternehmen, die Software außerhalb des Store erwerben

App-Installer-Datei Übersicht
→ Apps automatisch aktualisieren und reparieren

Verpackung mit externem Standort (Sparpaket)

Wenn Sie über eine vorhandene App mit einem eigenen Installationsprogramm (WiX, NSIS, InstallShield) verfügen und Windows-Features hinzufügen möchten, die eine Paketidentität erfordern, ohne das Installationsprogramm durch MSIX zu ersetzen, verwenden Sie Verpacken mit externem Speicherort.

Was Sie erhalten:

• Paketidentität ohne Änderung des Installationsprogramms oder der binären Speicherorte
• Zugriff auf Windows Features: Benachrichtigungen, Hintergrundaufgaben, Dateitypzuordnungen, Protokollhandler
• Ihr vorhandener Installations- und Updatemechanismus bleibt vorhanden

Was Sie nicht erhalten:

• Direkte MSIX Store-Übermittlung (das sparse-Paket ist nicht selbst vom Store übermittelt. Ihr zugrunde liegendes Installationsprogramm kann jedoch über den MSI/EXE Store-Installationspfad übermittelt werden)
• Das saubere Installations-/Deinstallationsmodell von vollständiger MSIX

Wann Sie dies wählen sollten:

• Sie verfügen über eine vorhandene Win32/WPF/WinForms-App mit einem etablierten Installationsprogramm
• Sie möchten bestimmte Windows API-Features, die paketidentität erfordern
• Die vollständige Migration zu MSIX ist zur zeit nicht machbar.

→ Gewähren der Paketidentität durch Verpacken mit externem Speicherort

Entpackt WinUI 3

Entpackte Verteilung entfernt MSIX vollständig aus dem Bild – die App wird direkt aus einem Ordner ohne Paketmanifest ausgeführt. Dies ist eine Nischenoption, die für bestimmte Szenarien geeignet ist.

Was Sie erhalten:

• Einfachere Buildausgabe (ein Ordner mit Dateien, keine MSIX-Tools)
• Keine MSIX-Infrastruktur auf Zielcomputern erforderlich
• Funktioniert auf Computern, auf denen MSIX Sideloading nicht aktiviert ist

Limitations:

• No single-file EXE - Die Windows App SDK-Laufzeit muss als separate Dateien zusammen mit der ausführbaren Datei bereitgestellt werden.
• Runtime-Bereitstellung – Sie müssen das Windows App SDK-Laufzeitinstallationsprogramm bündeln oder eine selbständige Bereitstellung verwenden (größeres Output)
• Keine Paketidentität – Keine automatischen Updates, keine Hintergrundaufgaben, keine Dateitypzuordnungen über das Manifest
• Keine MSIX/package-identity Store-Übermittlung – Dieses Modell hat keine Paketidentität und kann nicht als MSIX-Paket an den Store übermittelt werden. Ein herkömmliches Installationsprogramm (MSI/EXE) kann separat übermittelt werden, aber das liegt außerhalb dieses Verteilungspfads.
• SmartScreen-Warnungen, es sei denn, sie sind mit einem vertrauenswürdigen Zertifizierungsstellenzertifikat signiert

Wann Sie dies wählen sollten:

• Ihre Zielumgebung kann MSIX nicht verwenden (ungewöhnlich; die meisten verwalteten Unternehmensumgebungen unterstützen MSIX)
• Sie erstellen ein internes Tool, bei dem MSIX-Overhead nicht gerechtfertigt ist

Für die meisten WinUI 3-Apps ist MSIX (über Den Store oder direkten Download) der bessere Pfad. Die oben genannten Einschränkungen überraschen häufig Entwickler, die sie entdecken, nachdem sie in die entpackte Verteilung investiert haben.

→ Verteilen einer entpackten WinUI 3-App – schrittweise Anleitung mit Laufzeitbereitstellungsoptionen

Viele Windows Apps werden mithilfe von ClickOnce, MSI, WiX, Inno Setup oder ähnlichen Technologien verteilt. Dies sind etablierte und unterstützte Optionen, insbesondere für Apps, die MSIX nicht verwenden können oder keine Store-Verteilung benötigen. In der folgenden Tabelle sind die allgemeinen Optionen und deren Kompromisse zusammengefasst.

ClickOnce

ClickOnce ist eine in Visual Studio integrierte .NET Bereitstellungstechnologie. Es hostet ein Manifest auf einem Webserver oder einer Dateifreigabe; Benutzer installieren über die Manifest-URL, und ClickOnce verarbeitet die Überprüfung von Updates beim Start. Es eignet sich gut für WPF- und WinForms-Apps, die an eine bekannte Benutzerbasis verteilt werden.

ClickOnce wird für WinUI 3-Apps nicht unterstützt. Verwenden Sie MSIX mit .appinstaller für den WinUI 3 Direktvertrieb.

→ ClickOnce-Sicherheit und -Bereitstellung

MSI, WiX, Inno Setup und NSIS

Herkömmliche EXE- und MSI-Installationsprogramme bleiben für Windows Apps mit komplexen Installationsanforderungen (Treiberinstallation, Systemdienste, Registrierungskonfiguration) üblich. Tools wie WiX Toolset, Inno Setup und NSIS werden von der Community verwaltet und häufig verwendet. Für die Updateunterstützung ist eine eigene Implementierung erforderlich.

Diese Formate sind nicht für den Verkauf im Store als MSIX-Pakete geeignet, können aber über den MSI/EXE-Installationspfad an den Store übermittelt werden (erfordert eine Zertifikatverkettung an eine Zertifizierungsstelle im Microsoft Trusted Root Program und ein im Hintergrund installierendes Installationsprogramm). Sie können sie auch mit Packaging mit externem Speicherort kombinieren, wenn Sie eine Paketidentität für bestimmte Windows Features benötigen.

Eigenständige EXE (xcopy-Bereitstellung)

dotnet publish --self-contained erzeugt einen Ordner mit Dateien (oder einer EXE-Datei), den Benutzer ausführen können, ohne .NET zu installieren. Dies ist das einfachste Verteilungsmodell, erfordert jedoch, dass Benutzer eine neue Version manuell herunterladen. Es eignet sich für Befehlszeilentools, Entwicklerprogramme und Power-User-Apps.

winget – Hinzufügen der Auffindbarkeit zu einem beliebigen Verteilungspfad

Unabhängig vom Verpackungsformat können Sie ein Manifest an das Windows Paket-Manager Community-Repository übermitteln, damit Ihre App über winget install <your-app> installiert werden kann. Dadurch wird Ihre vorhandene Verteilungsmethode nicht ersetzt. Sie fügt einen Befehlszeileninstallationspfad hinzu, der von Entwickler- und technischen Zielgruppen geschätzt wird.

Verwandte Inhalte

• Übersicht über die Verpackung
• SmartScreen-Reputation für Windows App-Entwickler
• Aktueller Stand der Funktionen zur Verbreitung von Windows-Apps
• Publishen Sie im Microsoft Store
• Progressive Web-Apps Übersicht
• Azure Artifact Signing (vormals vertrauenswürdige Signatur)