Übersicht über die Bereitstellung des Windows App SDK

Es gibt zwei Möglichkeiten, wie Sie die Windows App SDK bereitstellen können:

  • Framework-abhängig. Ihre App hängt vom Windows App SDK Laufzeit- und/oder Framework-Paket ab, das auf dem Zielcomputer vorhanden ist. Frameworkabhängige Bereitstellung ist der Standardbereitstellungsmodus des Windows App SDK für effiziente Nutzung von Computerressourcen und Wartbarkeit.
  • eigenständige. Ihre App trägt die Windows App SDK Abhängigkeiten damit, ohne dass eine separate Laufzeitinstallation auf dem Zielcomputer erforderlich ist.

In diesem Thema werden auch die Begriffe verpackte App, verpackte App mit externem Speicherort und entpackte App verwendet. Erläuterungen zu diesen Begriffen finden Sie in der Übersicht über die Bereitstellung.

Bereitstellen einer frameworkabhängigen Anwendung Eigenständige Bereitstellung
Vorteile Kleine Bereitstellung. Nur Ihre App und ihre anderen Abhängigkeiten werden verteilt. Das Windows App SDK Laufzeit- und Framework-Paket werden automatisch von frameworkabhängigen Apps installiert, die verpackt sind, oder als Teil des Windows App SDK Laufzeitinstallationsprogramms durch frameworkabhängige Apps, die entweder mit externem Speicherort verpackt oder entpackt werden.

Dienstfähig. Wartungsupdates für die Windows App SDK werden automatisch über das Windows App SDK Framework-Paket installiert, ohne dass eine Aktion der App erforderlich ist.		 Control Windows App SDK Version. Sie steuern, welche Version der Windows App SDK mit Ihrer App bereitgestellt wird. Wartungsupdates der Windows App SDK wirken sich nicht auf Ihre App aus, es sei denn, Sie erstellen sie neu, und verteilen sie erneut.

Isoliert von anderen Apps. Apps und Benutzer können Ihre Windows App SDK Abhängigkeit nicht deinstallieren, ohne die gesamte App zu deinstallieren.

Xcopy-Bereitstellung. Da die Abhängigkeiten des Windows App SDK in Ihrer App enthalten sind, können Sie Ihre App bereitstellen, indem Sie die Build-Ergebnisse einfach per XCOPY kopieren, ohne zusätzliche Installationsanforderungen.
Nachteile Zusätzliche Installationsabhängigkeiten. Erfordert die Installation des Windows App SDK Laufzeit- und/oder Framework-Pakets, das der App-Installation Komplexität verleihen kann.

Geteilte Abhängigkeiten. Das Risiko besteht, dass freigegebene Abhängigkeiten deinstalliert werden. Apps oder Benutzer, die die freigegebenen Komponenten deinstallieren, können sich auf die Benutzererfahrung anderer Apps auswirken, die die Abhängigkeit gemeinsam nutzen.

Kompatibilitätsrisiko. Risiko, dass Wartungsupdates für die Windows App SDK zu wichtigen Änderungen führen. Während Wartungsupdates Abwärtskompatibilität bieten sollten, ist es möglich, dass Regressionen eingeführt werden.		 Größere Bereitstellungen (nur entpackte Apps) Da Ihre App die Windows App SDK enthält, sind die erforderliche Downloadgröße und der erforderliche Festplattenspeicher größer als bei einer frameworkabhängigen Version.

Leistung (nur entpackte Apps) Langsameres Laden und verwendet mehr Arbeitsspeicher, da Codeseiten nicht für andere Apps freigegeben werden.

Nicht bearbeitbar. Die Windows App SDK-Version, die mit Ihrer App verteilt wird, kann nur aktualisiert werden, indem Sie eine neue Version Ihrer App veröffentlichen. Sie sind für die Integration von Wartungsupdates der Windows App SDK in Ihre App verantwortlich.

Siehe auch Erstellen Sie Ihr erstes WinUI 3-Projekt und Verwenden Sie das Windows App SDK in einem bestehenden Projekt.

Note

PublishSingleFile (Exe-Datei) wird für entpackte, eigenständige WinUI 3-Apps (Windows App SDK 1.5 und höher) unterstützt. Verpackte Apps und frameworkabhängige Apps unterstützen PublishSingleFilenicht. Siehe Einzeldatei-EXE für die erforderlichen MSBuild-Eigenschaften.

Weitere Informationen zur framework-abhängigen Bereitstellung

Bevor Sie Ihre frameworkabhängige App für die Bereitstellung konfigurieren, um mehr über die Abhängigkeiten zu erfahren, die Ihre App bei der Verwendung des Windows App SDK hat, lesen Sie Deployment-Architektur für das Windows App SDK.

Verpackte Apps

Wenn Sie sich für eine frameworkabhängige verpackte App entschieden haben (siehe Deployment overview), finden Sie hier Anweisungen zum Bereitstellen der Windows App SDK Runtime mit der App:

Verpackt mit externen Speicherorten oder entpackten Apps

Wenn Sie sich für eine frameworkabhängige verpackte App mit externem Speicherort oder einer frameworkabhängigen, entpackten App entschieden haben (siehe Deployment overview), finden Sie hier Anweisungen zum Bereitstellen der Windows App SDK Laufzeit mit der App:

Weitere Informationen zur eigenständigen Bereitstellung

Siehe Windows App SDK Bereitstellungshandbuch für eigenständige Apps.

Note

PublishSingleFile (single-file EXE) setzt voraus, dass die App sowohl nicht paketiert als auch eigenständig ist. Die vollständige Liste der erforderlichen MSBuild-Eigenschaften finden Sie unter Single-file EXE.

Windows App SDK initialisieren

Die Art und Weise, wie Sie das Windows App SDK initialisieren sollten, hängt davon ab, ob und wie Sie Ihre App verpacken und wie Sie in Bezug auf die Windows App SDK-Laufzeit bereitstellen. Verwenden Sie den folgenden Abschnitt, der für Ihre App gilt.

Verpackte Apps

Wie Ihre App bereitgestellt wird Wie man initialisiert
Framework-abhängig Siehe zum Aufrufen der Bereitstellungs-API.
In sich geschlossen Keine Initialisierung erforderlich.

Entpackte Apps und Apps, die mit externem Speicherort verpackt sind

Wie Ihre App bereitgestellt wird Wie man initialisiert
Framework-abhängig Siehe Verwenden der Bootstrapper-API in einer App, die mit externem Speicherort verpackt oder nicht verpackt ist.
In sich geschlossen Siehe Deaktivieren (oder Aktivieren) der automatischen UndockedRegFreeWinRT-Unterstützung.

Überlegungen zur Architektur (x64, ARM64)

Wenn Sie Ihre App bereitstellen, müssen Sie Binärdateien für jede prozessorarchitektur einschließen, die Ihre Benutzer benötigen. Dies gilt sowohl für frameworkabhängige als auch eigenständige Bereitstellungsmodi.

ARM64-Unterstützung

Windows auf ARM-Geräten (einschließlich Surface Pro X, Surface Pro 11 und Copilot+ PCs) führen ARM64 nativ aus. Während die x64-Emulation auf Windows 11 ARM64-Geräten verfügbar ist, bieten systemeigene ARM64-Binärdateien eine bessere Leistung und Akkulaufzeit – und werden empfohlen, wenn Sie die beste Erfahrung für AI-Workloads auf Geräten auf Copilot+ PCs wünschen.

Native ARM64-Bereitstellung

  • MSIX-Bündel – Erstellen Sie ein .msixbundle Paket, das beide x64 und ARM64 Architekturen enthält. Visual Studio generiert diese automatisch, wenn Sie für mehrere Plattformen erstellen. Der Store- und App-Installer wählen die richtige Architektur zur Installationszeit aus.

  • Eigenständige Veröffentlichung – Geben Sie den Laufzeitbezeichner (RID) für jede Architektur an:

    dotnet publish -c Release -r win-x64 --self-contained true
dotnet publish -c Release -r win-arm64 --self-contained true

  • C++/WinRT – Erstellen Sie separate Konfigurationen für x64 und ARM64 in Ihrer Visual Studio Lösung.

  • Frameworkabhängige Apps – Stellen Sie bei Verwendung des Windows App SDK Laufzeitinstallationsprogramms sicher, dass Sie das richtige architekturspezifische Installationsprogramm bereitstellen. Die Windows App SDK enthält separate Installationsprogramme für x64 und ARM64.

Arm64EC – schrittweise Migration für große C/C++-Codebasen

Wenn Ihre App über eine große systemeigene Codebasis (C/C++) verfügt, ist eine vollständige Neukompilierung auf ARM64 in einem einzigen Schritt möglicherweise nicht praktikabel. Mit Arm64EC (Emulation compatible) können Sie x64- und ARM64-Code im selben Prozess kombinieren. Sie kompilieren leistungskritische Module nativ für ARM64 neu, während die verbleibenden x64-Module unter Emulation ausgeführt werden – alles in einer einzigen Binärdatei.

Approach Am besten geeignet für Kompromiss
Vollständiges ARM64-Neukompilieren Reine .NET-Apps, kleine C++-Projekte Beste Leistung; erfordert, dass alle Abhängigkeiten ARM64-kompatibel sind
Arm64EC Große C/C++-Apps, Apps mit nur x64-Plug-Ins oder DLLs von Drittanbietern Inkrementelle Migration; Emulierte Teile laufen langsamer als systemeigene Teile
Nur x64 (emuliert) Apps, die nicht neu kompiliert werden können und keine Spitzenleistung benötigen Einfachste; Reduzierte Akkulaufzeit und höhere Latenz auf ARM64-Geräten

Weitere Informationen finden Sie unter Arm64EC – Erstellen und Portieren von Apps für systemeigene Leistung auf Arm.

Emulation (Prism)

Windows 11 auf ARM verwendet eine Emulationsebene namens Prism zum Ausführen von x64- und x86-Apps auf ARM64-Hardware. Prism übersetzt x86/x64-Anweisungen zur Laufzeit in ARM64 und bietet eine umfassende App-Kompatibilität, ohne dass eine erneute Kompilierung erforderlich ist.

  • x64-Emulation – Nur auf Windows 11 ARM64-Geräten (nicht auf ARM Windows 10) verfügbar.
  • x86-Emulation – Verfügbar auf Windows 10- und Windows 11 ARM64-Geräten.
  • Leistung – Emulierte Apps werden in der Regel mit akzeptabler Leistung für Produktivitätsworkloads ausgeführt, grafikintensive oder rechenintensive Apps profitieren jedoch erheblich von einem systemeigenen ARM64- oder Arm64EC-Build.

Tip

Wenn Sie nur auf x64 abzielen, wird Ihre App weiterhin auf ARM64-Geräten über Prism-Emulation ausgeführt (nur Windows 11). Systemeigene ARM64-Builds werden jedoch für Produktions-Apps dringend empfohlen – emulierte Apps verwenden mehr Akku und weisen eine höhere Latenz auf. Auf Copilot+ PCs kann systemeigene ARM64 die beste Leistung für AI-Workloads auf Geräten bieten.

Laden Sie für Store-Übermittlungen architekturspezifische Pakete oder ein Bundle hoch, das beides enthält. Der Store liefert nur die passende Architektur für jedes Gerät.

  • Last updated on