Übersicht über die Verpackung

Das Verpacken definiert, wie Ihre App mit Windows installiert, aktualisiert und integriert wird. WinUI 3-Apps werden standardmäßig verpackt, während viele Desktop-Apps, z. B. herkömmliche Win32-Anwendungen, entpackt ausgeführt werden. Die Auswahl zwischen einer verpackten oder entpackten App wirkt sich auf die Features aus, die Sie verwenden können, das Bereitstellungsmodell, auf das Sie sich verlassen, und die allgemeine Benutzererfahrung, die Ihre Kunden erhalten.

Hinweis

Erstellen einer neuen WinUI 3-App? Sie sind bereits standardmäßig gepackt. Die nachstehende Anleitung ist für Entwickler relevant, die eine explizite Auswahl treffen müssen – in der Regel beim Portieren einer vorhandenen App, beim Bereitstellen auf Unternehmenscomputern oder beim Hinzufügen von Windows Features zu einer App, die ursprünglich nicht verpackt wurde.

Warum das Verpacken von Apps wichtig ist

Gepackte Apps profitieren von einem sauberen Installationsmodell, automatischen Updates und Zugriff auf Windows-Features, die eine Paketidentität erfordern – einschließlich Hintergrundaufgaben, Benachrichtigungen, Kontextmenüerweiterungen, Freigabeziele und andere Erweiterbarkeitspunkte. Das Verpacken trägt auch dazu bei, sauberere Bereitstellungen, zuverlässige Updates und optimierte Verteilung über Kanäle wie die Microsoft Store- und Unternehmensbereitstellungstools sicherzustellen.

Features, für die Paketidentität benötigt wird

Viele Windows-Features funktionieren nur in Apps, die über eine Paketidentität verfügen, entweder durch vollständiges MSIX-Packaging oder Paketierung mit externem Speicherort (Sparse Packaging). Beispiele sind Hintergrundaufgaben, Pushbenachrichtigungen, Freigabeziele, benutzerdefinierte Kontextmenüerweiterungen, manifestbasierte Dateityp- und Protokollzuordnungen und die Windows AI-APIs.

Die vollständige Liste finden Sie unter Features, die paketidentität erfordern.

Tipp

Wenn Sie entpackt sind und auf E_ILLEGAL_METHOD_CALL- oder APPMODEL_ERROR_NO_PACKAGE-Fehler beim Aufrufen von Windows-APIs stoßen, liegt dies an der Paketidentitätsanforderung. Betrachten Sie Verpackungen mit externer Lokation (Sparse Packaging) als eine Lösung mit minimaler Reibung.

Um zur Laufzeit zu erkennen, ob Ihr Prozess über eine Paketidentität verfügt, verwenden Sie GetCurrentPackageFullName. Siehe Ist dies ein verpackter Prozess? im Inside MSIX-Blog für kanonische C++- und C#-Beispiele.

Verpackungsmodelle auf einen Blick

Modell Paketidentität Installationsprogramm Berechtigter Store Am besten geeignet für:
Verpackt (MSIX) ✅ Ja MSIX ersetzt installationsprogramm ✅ Ja (MSIX-Übermittlung) Neue Apps, Store-Veröffentlichung, Unternehmens-MDM
Verpackung mit externem Speicherort ✅ Ja Ihr vorhandenes Installationsprogramm ✅ Ja (MSI/EXE Übermittlung) Vorhandene Apps mit eigenem Installationsprogramm, ISVs
Unverpackt ❌ Nein MSI- oder EXE-Installationsprogramm (auch: XCopy oder Skript für Nicht-Store-Verteilung) ✅ Ja (MSI/EXE-Übermittlung – erfordert ein MSI- oder EXE-Installationsprogramm mit unterstützung der automatischen Installation) Breite Win32-Verteilung, interne Tools

Verpackte Apps (MSIX)

Verpackte Apps verwenden MSIX und verfügen über Package Identity, die für viele Windows Erweiterbarkeitspunkte erforderlich ist. Die Paketidentität ermöglicht es Windows, den Aufrufer von Plattform-APIs zuverlässig zu identifizieren, weshalb diese Features davon abhängen.

  • Verpackte Apps werden in der Regel in einem einfachen App-Container mit Dateisystem- und Registrierungsvirtualisierung ausgeführt (siehe AppContainer für Ältere Apps und MSIX AppContainer-Apps).
  • Apps können auch so konfiguriert werden, dass sie bei Bedarf nicht in einem App-Container ausgeführt werden.
  • MSIX wird sowohl für die Verpackung als auch für die Installation verwendet (siehe Was ist MSIX?).

Verpackung mit externem Standort (spärliche Verpackung)

Durch das Verpacken mit externem Speicherort (auch als "Sparsepakete" bezeichnet) können Sie ein kleines Identitätspaket zusammen mit Ihrer vorhandenen App registrieren, ohne das Installationsprogramm, die binären Speicherorte oder den Aktualisierungsprozess zu ändern. Es wurde in Windows 10 Version 2004 (Build 19041) eingeführt.

Dies ist der optimale Punkt für vorhandene Win32/WPF/WinForms-Apps, die über ihr eigenes Setup (NSIS, WiX, InstallShield usw.) bereitgestellt werden und nicht durch MSIX ersetzt werden sollen. Sie registrieren ein leichtgewichtiges Identitätspaket, Ihre Binärdateien bleiben unverändert, und Sie schalten alle Windows-Funktionen frei, die durch Paketidentität gesteuert werden.

Fähigkeit MSIX Externer Speicherort
Ersetzt ihr Installationsprogramm Ja No
Binärdateien innerhalb des Pakets Ja Nein (extern)
Berechtigter Store Ja (MSIX-Übermittlung) Ja (MSI/EXE Übermittlung)
Paketidentität Ja Ja
Updatemechanismus MSIX-Aktualisierung Ihr vorhandener Mechanismus

→ Vollständige Anleitung: Zuweisung einer Paket-ID durch Verpackung mit externem Speicherort

Entpackte Apps

Entpackte Apps verwenden MSIX nicht und besitzen keine Paketidentität, was bedeutet, dass sie nicht auf die oben aufgeführten Features zugreifen können.

  • Sie bleiben in Bezug auf API-Oberfläche, Dateisystemzugriff, Registryzugriff, Rechteerhöhung und Prozessmodell uneingeschränkt.
  • Installation und Updates basieren auf .exe, .msi und benutzerdefinierten Installationsprogrammen, ClickOnce oder xcopy-Bereitstellung.

Bevor Sie sich für die Verwendung ohne Verpackung entscheiden, überprüfen Sie die obige Funktionstabelle anhand Ihrer Roadmap. Wenn Benachrichtigungen, Hintergrundaufgaben oder KI-APIs am Horizont liegen, sollten Sie das Paket starten.

Nach Szenario auswählen

Szenario Empfohlenes Modell Einzelheiten
Indie-Entwickler veröffentlicht im Microsoft Store Paketiert (MSIX) empfohlen MSIX ist der empfohlene Pfad – es ermöglicht vom Store verwaltete Updates, differenzielle Downloads und saubere Deinstallation. WinUI 3-Apps sind standardmäßig gepackt. Die Code-Signierung wird vom Store kostenlos übernommen. → Verteilen Ihrer verpackten App

Win32-Apps mit einem vorhandenen MSI- oder EXE-Installationsprogramm können auch über den MSI/EXE-Übermittlungspfad im Store veröffentlicht werden, aber der Store pusht keine Updates an vorhandene Benutzer – Updates müssen von der App oder dem Installationsprogramm behandelt werden.
Enterprise-App bereitgestellt über Intune oder Konfigurations-Manager Verpackter oder externer Speicherort für vorhandene Installationsprogramme Neue Apps sollten MSIX verwenden. Vorhandene Apps mit ihrem eigenen Installationsprogramm können Verpackungen mit externem Speicherort verwenden. Code signing: Verwenden Sie ein selbstsigniertes Zertifikat (vertrauenswürdig über Intune, Gruppenrichtlinie oder Konfigurations-Manager) oder Azure Artifact Signing (vormals Trusted Signing). → Bereitstellen von verpackten Apps
ISV versenden einen Direktdownload mit eigenem Installationsprogramm Verpacken mit Standort außerhalb Registrieren Sie ein einfaches Identitätspaket zusammen mit Ihrem vorhandenen Installationsprogramm. Code-Signatur: Für die Verteilung außerhalb des Stores ist ein CA-vertrauenswürdiges Zertifikat erforderlich. Azure Artifact Signing (ehemals vertrauenswürdige Signatur) ist die empfohlene Option für niedrigere Kosten. → Paketidentität gewähren

Alternativ können Sie Ihr vorhandenes Installationsprogramm über den MSI/EXE-Übermittlungspfad an den Store übermitteln.
Internes Tool oder Entwicklerprogramm Unverpackt Am einfachsten erstellen und bereitstellen. Die Windows App SDK funktioniert über NuGet, aber einige Features sind nicht verfügbar.

Tipp

Die Anforderungen und Kosten für die Codesignatur variieren je nach Verteilungspfad. Eine vollständige Aufschlüsselung Ihrer Optionen finden Sie unter Codesignaturoptionen für Windows App-Entwickler.

Frameworkabhängige und eigenständige Bereitstellung

Unabhängig vom Paketmodell wählen Apps, die die Windows App SDK verwenden, aus, wie ihre Laufzeitabhängigkeiten übertragen werden sollen: frameworkabhängig (die Windows App SDK Laufzeit wird auf dem Computer des Benutzers installiert) oder eigenständig (alle Windows App SDK Binärdateien werden mit Ihrer App ausgeliefert). Diese Auswahl ist unabhängig von der Verpackung.

Einen vollständigen Vergleichs- und Bereitstellungsleitfaden finden Sie in der Übersicht über die Windows App SDK Bereitstellung.

Erste Schritte mit MSIX

Wenn Sie eine Win32-Desktop-App (manchmal als classic-Desktop-App bezeichnet) oder eine .NET-App erstellen – einschließlich Windows Presentation Foundation (WPF) und Windows Forms (WinForms) – können Sie Ihre App mithilfe von MSIX packen und bereitstellen.

Migrieren von älteren Installern zu MSIX

Wenn Ihre App derzeit ein herkömmliches Installationsprogramm verwendet, können Sie zu MSIX migrieren, um eine saubere Installation und Deinstallation, automatische Updates, die Verteilung über den Store und eine Paketidentität zu erhalten. Der Migrationspfad hängt von Ihrer aktuellen Installationsprogrammtechnologie ab und ob Sie Zugriff auf den Quellcode haben.

Aktueller Installer Empfohlener Migrationspfad Quellcode erforderlich?
MSI (Windows Installer) Verwenden Sie das MSIX Packaging Tool , um die MSI direkt in MSIX zu konvertieren. Behandelt die meisten MSI-Muster, einschließlich benutzerdefinierter Aktionen. No
ClickOnce (.NET) Erstellen Sie das Projekt mithilfe des Visual Studio-MSIX-Paketprojekts aus dem Quellcode neu. ClickOnce-automatisches Update kann durch Store-Updates oder App-Installer ersetzt werden. Ja
InstallShield / Advanced Installer Verwenden Sie das MSIX Packaging Tool, um eine Installation auf einer sauberen VM zu erfassen. Komplexe benutzerdefinierte Aktionen benötigen möglicherweise manuelle Korrekturen im Paket-Editor. No
Inno Setup / NSIS Verwenden Sie den VM-basierten Aufnahmeworkflow des MSIX Packaging Tools. Führen Sie das EXE-Installationsprogramm in der sauberen Umgebung des Tools aus. No
App-V (virtuelle Pakete) Konvertieren Sie direkt mit dem MSIX Packaging Tool – es unterstützt App-V 5.x-Pakete als Eingabe. No
MSIX mit erforderlichen Änderungen Verwenden Sie das Paketunterstützungsframework , um Laufzeitfixes (Datei-/Registrierungsumleitung) anzuwenden, ohne den App-Code zu ändern. No

Tipp

Für Apps mit komplexen Installationsprogrammen mit Kerneltreibern, Diensten, die als SYSTEM ausgeführt werden, oder computerweite COM-Registrierungen, die MSIX nicht unterstützt, sollten Sie MSIX mit externem Speicherort (verpackt mit externem Speicherort ) in Betracht ziehen. Dadurch erhalten Sie die Paketidentität für Windows Features, während Sie ein herkömmliches Installationsprogramm für Komponenten verwenden, die erhöhten Zugriff erfordern. Weitere Informationen finden Sie unter Erteilen der Paketidentität durch Packen mit externem Speicherort.

Wichtige Überlegungen

  • Testen Auf einer sauberen VM – Das MSIX Packaging Tool erfasst alle Änderungen während der Installation. Führen Sie es auf einem sauberen Windows Image aus, um zu vermeiden, dass nicht verwandte Systemänderungen erfasst werden.
  • Paketsupportframework – Wenn Ihre konvertierte App Laufzeitprobleme hat (Dateipfadannahmen, Registrierungsschreibvorgänge in HKLM), kann das Paketunterstützungsframework diese beheben, ohne Ihre Quelle zu ändern.
  • Parallel zum klassischen Installationsprogramm — Sie können die MSIX-Version während der Übergangsphase parallel zum klassischen Installationsprogramm bereitstellen. Planen Sie eine explizite Einstellungen/Datenmigration (z. B. beim ersten Ausführen importieren), da sich Paketidentität und Speicherorte zwischen MSIX- und MSI/EXE-Installationen unterscheiden.

Andere Installationstechnologien

Verwandte Inhalte

  • Last updated on