Windows-Apps: Verpacken, Bereitstellung und Verarbeiten

In diesem Thema werden Ihre Optionen zu folgenden Themen erläutert:

  • Welche Verpackungsoption für Ihre App verwendet werden soll (verpackt, mit externem Speicherort verpackt oder entpackt).
  • Wie Sie Ihre App bereitstellen/verteilen und wie sie installiert wird.
  • Der Laufzeitprozess Ihrer App, einschließlich dessen, wie stark sie isoliert sein wird und welche APIs ihr zur Verfügung stehen werden.

Sie können diese Entscheidungen sowohl für neue als auch für vorhandene Apps treffen. Wenn Sie sich aber noch in der Planungsphase für eine neue App befinden, entscheiden Sie zuerst, welches Entwicklungsplattform- und Benutzeroberflächenframework Sie für Ihre App verwenden werden, bevor Sie mit den oben genannten Überlegungen beginnen. Und für diese Entscheidung finden Sie eine Übersicht über die Windows-Entwicklungsoptionen.

Verpackungsoptionen: verpackt, mit externem Speicherort verpackt oder unverpackt

Die Entscheidung darüber, welche Verpackungsoption für Ihre App verwendet werden soll, wird zuerst durch ein Konzept bestimmt, das als Paketidentität bezeichnet wird. Viele Windows-Erweiterungsfunktionen (Hintergrundaufgaben, Pushbenachrichtigungsszenarien, die die Hintergrundübermittlung oder COM-Aktivierung verwenden, benutzerdefinierte Kontextmenüerweiterungen und Freigabeziele) können von einer App nur dann verwendet werden, wenn diese App zur Laufzeit eine Paketidentität besitzt, da das Betriebssystem (OS) den Aufrufer der entsprechenden API identifizieren können muss. Nur verpackte Apps (einschließlich Apps, die an externem Speicherort verpackt sind) weisen die Paketidentität auf.

Eine vollständige Erläuterung der gepackten, der mit externem Speicherort gepackten und der ungepackten Modelle sowie Hinweise zur Auswahl zwischen ihnen finden Sie in der Übersicht über die Paketierung. Informationen zu den Features, die von der Paketidentität abhängen, finden Sie unter Features, die paketidentität erfordern.

Informationen zum Konfigurieren Ihrer App als verpackt oder unverpackt:

Weitere Informationen finden Sie im Abschnitt Windows Paket-Manager und winGet-Client in diesem Thema.

Bereitstellung/Verteilung/Installation

Eine verpackte App wird mit MSIX verpackt und installiert. Wenn Sie sich für ein Paket mit externem Speicherort entscheiden, handelt es sich um ein "Bring-your-own-installer"-Modell, sodass Sie das Installationsprogramm weiterhin selbst erledigen (siehe Erteilen der Paketidentität durch Verpacken mit externem Speicherort). Eine entpackte App umfasst msIX überhaupt nicht.

Die Paketierung ist wichtig, weil MSIX Ihren Benutzern eine saubere Installation, Deinstallation und Aktualisierung ermöglicht, inkrementelle und automatische Updates unterstützt, für den Microsoft Store optimiert ist, mit MSIX app attach für Azure Virtual Desktop funktioniert und bei Signierung von einem starken Manipulationsschutz profitiert.

Anleitungen zur Bereitstellung und Verteilung finden Sie unter Übersicht über Paketierung und Bereitstellung und Auswählen eines Verteilungspfads. Siehe auch den Abschnitt Windows Paket-Manager und WinGet-Client in diesem Artikel.

AppContainer oder Mittlere IL

Die Entscheidung, Ihre App in einem AppContainer laufen zu lassen oder nicht, ist eine Frage der Sicherheit. Der Prozess einer AppContainer-App und seine untergeordneten Prozesse werden in einem einfachen App-Container ausgeführt, in dem sie nur auf die Ressourcen zugreifen können, die ihnen speziell gewährt werden. Und sie sind durch Dateisystem- und Registrierungsvirtualisierung isoliert. Daher können in einem AppContainer implementierte Apps nicht gehackt werden, um schädliche Aktionen außerhalb der eingeschränkten zugewiesenen Ressourcen zuzulassen.

Verpackte oder entpackte Apps können so konfiguriert werden, dass sie in einem AppContainer ausgeführt werden. Der Prozess ist jedoch für verpackte Apps einfacher. Wenn es sich bei einer App nicht um eine AppContainer-App handelt, handelt es sich um eine Mittlere IL-App .

Weitere Informationen finden Sie unter AppContainer für ältere Apps und MSIX AppContainer-Apps.

Informationen zum Konfigurieren Ihrer App für die Ausführung in einem AppContainer oder mit mittlerem IL:

  • WinUI-Apps (Windows App SDK). Weitere Informationen finden Sie im App-Paketmanifest-Attribut in uap10:TrustLevel.
  • Desktop-Apps. Siehe die Visual Studio-Projekteigenschaft TrustLevel in MSIX AppContainer-Apps (im Abschnitt, der für Ihre Art von App geeignet ist).
  • Universal Windows Platform(UWP)-Apps. UWP-Apps sind bereits für die Ausführung in einem AppContainer konfiguriert. und diese Konfiguration kann nicht geändert werden.

Denken Sie daran, dass entpackte Apps nicht über ein App-Paketmanifest verfügen. Für entpackte Apps deklarieren Sie also Ihre AppContainer-oder-Medium-IL-Entscheidung in Ihrer Projektdatei anstelle eines App-Paketmanifests.

Win32-App-Isolation

Die Win32-App-Isolation ist eine Sicherheitsfunktion (verfügbar ab Windows 11, Version 24H2), die dazu beiträgt, den Schaden zu begrenzen, falls eine App kompromittiert wird, und die Datenschutzentscheidungen der Benutzer schützt. Es baut auf AppContainers und Komponenten auf, die Ressourcen virtualisieren und vermittelten Zugriff bieten. Weitere Informationen finden Sie unter Win32-App-Isolationsübersicht und der Win32-App-Isolation GitHub Repository.

App-Funktionen

App-Funktionen (z. B. InternetClient, Standort, Mikrofon und Bluetooth) sind hauptsächlich für verpackte Apps relevant, die in einem AppContainer ausgeführt werden. Dies umfasst also all Universelle Windows-Plattform (UWP)-Apps und some Desktop-Apps.

Es gibt jedoch einige Szenarien, in denen selbst eine Mittlere IL-App (d. h. keine AppContainer-App) eine Funktion deklarieren sollte. Ein Beispiel ist die eingeschränkte RunFullTrust-Funktion .

Weitere Informationen zu App-Funktionen, zu welchen Arten von Apps sie anwenden und wie sie konfiguriert werden, finden Sie unter App-Funktionsdeklarationen. Sie konfigurieren Funktionen im App-Paketmanifest; aus diesem Grund gelten sie nur für verpackte Apps.

Arten von Apps

Desktop-Apps und Universelle Windows-Plattform (UWP)-Apps sind die beiden Hauptarten von Apps, obwohl es verschiedene Arten von Apps in der Desktop-App-Familie gibt. Die Auswahl eines Benutzeroberflächenframeworks (WinForms, WPF, Win32, Direct 2D/3D oder WinUI 3) ist teilweise unabhängig von den in diesem Thema beschriebenen Konfigurationen.

Sehen wir uns jedoch an, wie sich diese App-Arten hinsichtlich Verpackung, Bereitstellung und Prozess voneinander unterscheiden können.

Zunächst werden alle UWP-Apps verpackt und in einem AppContainer ausgeführt. Für Desktop-Apps sind die Dinge jedoch flexibler. Sie können ihre Desktop-App verpacken oder nicht. Unabhängig von dieser Entscheidung können Sie ihre Desktop-App entweder als AppContainer oder als Mittlere IL-App konfigurieren.

Verpackt Unverpackt
AppContainer Desktop-Apps
UWP-Anwendungen		 Desktop-Apps
Mittlere IL Desktop-Apps Desktop-Apps

Zum Konfigurieren der gewünschten App-Art verwenden Sie für verpackte Apps das attribut uap10:RuntimeBehavior im App-Paketmanifest (siehe Application (Windows 10)).

  • Desktop-Apps sind Windows-Anwendungen, in der Regel mit einer .exe oder WinMain-Funktion als Einstiegspunkt. Um Ihre App als Desktop-App zu konfigurieren, legen Sie uap10:RuntimeBehavior auf entweder "packagedClassicApp" oder "win32App" fest.
    • Der Wert "packagedClassicApp" gibt entweder eine WinUI-App (Windows App SDK) oder eine Desktop-Brücke-App (Centennial) an. Der Unterschied besteht darin, dass eine Centennial-App in einem AppContainer ausgeführt wird.
    • Und "win32App" gibt jede andere Art von Win32-App an (einschließlich einer App, die mit externem Speicherort verpackt ist).
  • Die Einstellung uap10:RuntimeBehavior auf "windowsApp" bietet Ihnen schließlich eine UWP-App.

Alle Optionen für die Arten von Apps, die Sie entwickeln können, finden Sie unter Windows app Entwicklung: Optionen und Features.

Windows App SDK: frameworkabhängig oder eigenständig

Wenn Ihre App die Windows App SDK verwendet, wählen Sie auch aus, wie die SDK-Runtime bereitgestellt werden soll, von der Ihre App abhängig ist: frameworkabhängig (standard, wobei das Windows App SDK Laufzeit- und/oder Framework-Paket auf dem Zielcomputer vorhanden sein muss) oder eigenständig (Ihre App trägt die Windows App SDK Abhängigkeiten davon). Weitere Informationen finden Sie in der Übersicht über die Windows App SDK Bereitstellung.

Windows Paket-Manager und der WinGet-Client

Ein package manager kann Ihren Benutzern helfen, Ihre Software zu installieren/zu aktualisieren/zu konfigurieren, indem sie den Workflow automatisieren. Paketmanager können bei der Installation von Software helfen, sie werden jedoch meist verwendet, um developer tools zu installieren. Wenn Sie also ein Entwicklertool erstellen, sind Sie möglicherweise besonders an dieser Option interessiert. Aber so funktioniert es:

  • Als Softwareentwickler definieren Sie für die package manager (in Form von deklarativen Anweisungen) alle Teile, die für eine erfolgreiche Installation Ihres Produkts erforderlich sind.
  • Und wenn ein Benutzer Ihre Software installiert, folgt die package manager Ihren deklarativen Anweisungen, um den Installations- und Konfigurationsworkflow zu automatisieren.

Das Ergebnis ist eine Reduzierung der Zeit für die Vorbereitung der Umgebung eines Benutzers und eine bessere Kompatibilität zwischen den installierten Komponenten. Außerdem können Sie Windows Paket-Manager verwenden, um Ihre verpackten oder entpackten Apps in Formaten wie .msix, .msi und .exe zu verteilen.

Weitere Informationen finden Sie unter Windows Paket-Manager.

  • Last updated on