Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Hinweis
Erstellen einer neuen WinUI 3-App? Sie sind bereits standardmäßig gepackt. Diese Seite richtet sich an Entwickler, 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.
Windows-Apps können verpackt, entpackt oder irgendwo dazwischen verpackt werden. Die richtige Wahl hängt von zwei Dingen ab: wie Sie Ihre App verteilen und welche Windows-Features Sie benötigen.
Beginnen Sie mit Ihrem Szenario
"Ich bin ein Indie-Entwickler, der im Microsoft Store veröffentlicht wird"
Verwenden Sie eine verpackte MSIX-App. Der Store erfordert MSIX-Verpackungen. WinUI 3-Apps, die in Visual Studio erstellt wurden, sind standardmäßig gepackt– Sie müssen keine Änderungen vornehmen. Sie erhalten eine saubere Installation, automatische Updates und Zugriff auf alle paketidentitätsgeschützten Funktionen wie Benachrichtigungen und Hintergrundaufgaben.
→ Verteilen Ihrer verpackten App
"Ich baue eine Unternehmens-App, die über Intune oder Configuration Manager bereitgestellt wird"
Fertig verpackt starten; Ziehen Sie einen externen Speicherort in Betracht, wenn Sie bereits über ein Installationsprogramm verfügen.
- Wenn Sie eine neue App erstellen, verwenden Sie MSIX. Es ist sauber in Intune und SCCM/ConfigMgr integriert und bietet Ihnen die vollständige Paketidentität.
- Wenn Sie über eine vorhandene App mit einem eigenen Installationsprogramm verfügen, das Sie nicht ersetzen können, verwenden Sie das Verpacken mit externem Speicherort. Dadurch erhalten Sie die Identität Ihres App-Pakets und den Zugriff auf Features wie Benachrichtigungen und Hintergrundaufgaben, ohne zu ändern, wie oder wo Sie bereitstellen.
- Wenn Ihre App wirklich keine Windows-Identity-Gated-Features benötigt und Sie die Bereitstellungsumgebung kontrollieren, funktionieren nicht paketierte Apps, aber Sie stoßen an Grenzen, sobald Sie versuchen, Benachrichtigungen oder KI-Funktionen hinzuzufügen.
→ Bereitstellen verpackter Apps (Windows App SDK)
→ Gewähren der Paketidentität durch Verpacken mit externem Speicherort
Ich bin ein ISV und biete einen direkten Download mit meinem eigenen Installationsprogramm an.
Verwenden Sie Verpackungen mit externem Speicherort (früher als Sparsepakete bezeichnet).
Dies ist der ideale Punkt für bestehende Win32/WPF/WinForms-Apps, die über ihr eigenes Installationsprogramm (NSIS, WiX, InstallShield usw.) bereitgestellt werden und nicht durch MSIX ersetzt werden wollen. Sie registrieren ein leichtgewichtiges Identitätspaket zusammen mit Ihrem vorhandenen Installationsprogramm, Ihre Binärdateien bleiben dort, wo sie sind, und Sie entsperren die durch Paketidentität gesperrten Windows-Features in vollem Umfang.
Ihre Benutzer sehen keine Änderung der Installation oder Aktualisierung Ihrer App. Sie erhalten die Windows-Features; sie erhalten eine vertraute Erfahrung.
→ Gewähren der Paketidentität durch Verpacken mit externem Speicherort
→ Hinzufügen eines Identitätspakets in Visual Studio
"Ich baue ein internes Tool oder Entwicklerprogramm"
Entpackt ist in Ordnung – mit Vorbehalten.
Entpackte Apps sind am einfachsten zu erstellen und bereitzustellen: Xcopy, Robocopy oder ein einfaches Skript ist alles, was Sie benötigen. Das Windows App SDK funktioniert in entpackten Apps über NuGet. Einige Features werden jedoch nicht verfügbar sein, und wenn Sie später feststellen, dass Sie diese benötigen, ist die Einbindung der Paketidentität nicht trivial.
Bevor Sie sich für das Entpacken verpflichten, überprüfen Sie die nachstehende Featuretabelle anhand Ihrer Roadmap. Wenn Benachrichtigungen, Hintergrundaufgaben oder KI-APIs am Horizont liegen, sollten Sie das Paket starten.
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 |
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 Verpackungen mit externem Speicherort.
| Funktion | Hinweise |
|---|---|
| App-Benachrichtigungen (Toast) |
AppNotificationManager erfordert Paketidentität |
| Hintergrundaufgaben | Für die Registrierung ist eine Paketidentität erforderlich. |
| Windows AI-APIs (Phi-Silika, OCR usw.) | Die meisten Windows AI-APIs erfordern paketidentität |
| Pushbenachrichtigungen (WNS) | Kanalregistrierung erfordert Paketidentität |
| Freigabeziel | Im Paketmanifest deklariert |
| Benutzerdefinierte Kontextmenüerweiterungen | Im Paketmanifest deklariert |
| Dateityp- und Protokollzuordnungen | Umfangreiche Zuordnungen erfordern paketidentität |
| Startaufgaben | Erfordert Paketidentität |
| App-Dienste | Erfordert Paketidentität |
Tipp
Wenn Sie entpackt sind und beim Aufrufen von Windows-APIs auf E_ILLEGAL_METHOD_CALL- oder APPMODEL_ERROR_NO_PACKAGE-Fehler stoßen, liegt dies an der Paketidentitätsanforderung. Sehen Sie Verpackungen mit externem Standort als Lösung mit minimalem Reibungsverlust an.
Verpacken mit Standort außerhalb
Durch das Verpacken mit externen Speicherorten (auch als "Sparsepakete" bezeichnet) können Sie ein kleines Identitätspaket zusammen mit Ihrer vorhandenen App registrieren, ohne dass Sie das Installationsprogramm, die binären Speicherorte oder den Aktualisierungsprozess ändern müssen. Es wurde in Windows 10 Version 2004 (Build 19041) eingeführt.
Sie stellen Folgendes bereit:
- Ein Paketmanifest (XML-Datei, die Ihre App-Identität beschreibt)
- Ein signiertes
.msixElement, das nur das Manifest enthält (keine Binärdateien)
Ihr vorhandenes Installationsprogramm registriert dieses Identitätspaket, und Windows behandelt Ihre App ab diesem Zeitpunkt als eine App mit Paketidentität.
Dies unterscheidet sich von der vollständigen MSIX-Verpackung:
| 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
Frameworkabhängige und eigenständige Bereitstellung
Unabhängig vom Paketmodell wählen Apps mit dem Windows App SDK aus, wie ihre Laufzeitabhängigkeiten übertragen werden:
- Rahmenabhängig: Die SDK-Laufzeit des Windows-App muss auf dem Computer des Benutzers installiert sein. Geringerer App-Speicherbedarf; basiert auf der Laufzeit, die vorhanden oder automatisch installiert wird.
- Eigenständig: Alle Binärdateien des Windows App SDK werden mit Ihrer App ausgeliefert. Größerer Fußabdruck; keine externe Laufzeitanforderung. Gut für gesperrte Unternehmensumgebungen.
→ Bereitstellen eigenständiger Apps
Verwandte Inhalte
Zusammenarbeit auf GitHub
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
Windows developer