Freigeben über

Ü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

Diese Windows Features funktionieren nur in Apps mit Paketidentität – entweder über vollständige MSIX-Verpackungen oder Packaging mit externem Speicherort (Sparse packaging).

Funktion Beschreibung
Hintergrundaufgaben Führen Sie Code aus, wenn sich Ihre App nicht im Vordergrund befindet , z. B. um Daten zu synchronisieren, Downloads zu verarbeiten oder auf Systemereignisse zu reagieren.
Windows AI-APIs (Phi-Silika, OCR usw.) Greifen Sie auf KI-Funktionen wie lokale Sprachmodelle, Texterkennung und Bildanalyse zu.
Pushbenachrichtigungen (WNS) Empfangen Sie Echtzeitbenachrichtigungen von Ihrem Clouddienst über den Windows-Benachrichtigungsdienst.
Freigabeziel Ermöglichen Sie Benutzern, Inhalte aus anderen Apps direkt über das Systemfreigabeblatt in Ihre Apps zu teilen.
Benutzerdefinierte Kontextmenüerweiterungen Fügen Sie die Aktionen Ihrer App dem Kontextmenü des Datei-Explorers und anderer Shelloberflächen hinzu.
Dateityp- und Protokollzuordnungen Registrieren Sie Ihre App als Handler für bestimmte Dateitypen oder URI-Protokolle (z. B yourapp://. ).
Startaufgaben Starten Sie Ihre App automatisch, wenn sich der Benutzer bei Windows anmeldet.
App-Dienste Machen Sie Hintergrunddienste verfügbar, die andere Apps aufrufen können, wodurch die Kommunikation zwischen Apps ermöglicht wird.

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.

Weitere Informationen finden Sie unter Features, die Paketidentität erfordern.

Verpackungsmodelle auf einen Blick

Modell Paketidentität Installationsprogramm Berechtigter Store Am besten geeignet für:
Verpackt (MSIX) ✅ Ja MSIX ersetzt installationsprogramm ✅ Ja Neue Apps, Store-Veröffentlichung, Unternehmens-MDM
Verpacken mit externem Standort ✅ Ja Ihr vorhandenes Installationsprogramm ❌ Nein Vorhandene Apps mit eigenem Installationsprogramm, ISVs
Unverpackt ❌ Nein XCopy / Skript ❌ Nein Interne Tools, Entwicklerprogramme, einfache Szenarien

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 No
Paketidentität Ja Ja
Updatemechanismus MSIX-Aktualisierung Ihr vorhandener Mechanismus

Komplette Anleitung: Gewähren der Paketidentität durch Paketieren 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 Verpackt (MSIX) Der Store erfordert MSIX. WinUI 3-Apps werden standardmäßig verpackt – keine Änderungen erforderlich. Die Code-Signierung wird vom Store kostenlos übernommen. → Verteilen Ihrer verpackten App
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
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

Sie sind nicht sicher, was die Kosten für die Codesignatur sind? Die Veröffentlichung über den Microsoft Store bedeutet, dass Sie kein Zertifikat für das Vertrauen der Endbenutzer gesondert abrufen oder verwalten müssen. Bei anderen Verteilungspfaden hängt Ihr Signaturansatz vom Bereitstellungskontext ab. Unternehmensumgebungen können einem selbstsignierten Zertifikat über die Geräteverwaltung vertrauen, während eine breitere Verteilung ohne Store normalerweise eine Ca-vertrauenswürdige Codesignaturlösung erfordert. Azure Artifact Signing (ehemals vertrauenswürdige Signatur) ist die von Microsoft empfohlene Option (siehe Preisgestaltung), ohne dass ein Hardware-Token erforderlich ist.

Frameworkabhängige und eigenständige Bereitstellung

Apps, die die Windows App SDK verwenden, wählen getrennt vom Paketmodell aus, wie ihre Laufzeitabhängigkeiten übertragen werden:

  • Framework-abhängig: Die Windows-App-SDK-Runtime muss auf dem Computer des Benutzers installiert sein. Geringerer App-Speicherbedarf; basiert auf der Laufzeit, die vorhanden oder automatisch installiert wird.
  • Self-contained: Alle Windows App SDK Binärdateien werden mit Ihrer App ausgeliefert. Größerer Fußabdruck; keine externe Laufzeitanforderung. Gut für gesperrte Unternehmensumgebungen.

→ Bereitstellen eigenständiger Apps

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.

Andere Installationstechnologien

Verwandte Inhalte

  • Last updated on