Grundlegendes zur Funktion von verpackten Desktop-Apps unter Windows

  • Artikel

In diesem Thema werden die Typen von Desktop-Apps beschrieben, für die Sie ein Windows-App-Paket erstellen können. Außerdem werden einige Verhaltensweisen des Betriebssystems sowie weitere Besonderheiten erläutert, die es zu beachten gilt. Auf folgende Elemente gehen wir näher ein (wie wir sehen werden, hängt das spezifische Verhalten vom App-Typ ab):

Typen von Desktop-Apps

Es gibt zwei Typen von Desktop-Apps, die Sie erstellen und verpacken können. Den Typ der App deklarieren Sie im App-Paketmanifest mithilfe des Attributs uap10:RuntimeBehavior des Elements Anwendung:

  • Ein Typ umfasst WinUI 3-Apps (die das Windows App SDK verwenden) und Desktop-Brücke-Apps (Centennial). Deklariert mit uap10:RuntimeBehavior="packagedClassicApp".
  • Der andere Typ stellt andere Arten von Win32-Apps dar, darunter Apps , die mit einem externem Speicherort verpackt sind. Deklariert mit uap10:RuntimeBehavior="win32App".

Apps der Universellen Windows-Plattform (UWP) (uap10:RuntimeBehavior="windowsApp") werden ebenfalls verpackt. Diese werden in diesem Thema jedoch nicht behandelt.

Anschließend bestimmt das Attribut uap10:TrustLevel (desselben Elements Anwendung), ob der Prozess der verpackten App in einem App-Container ausgeführt wird.

  • Eine voll vertrauenswürdige App. Deklariert mit uap10:TrustLevel="mediumIL".
  • Eine appContainer-App. Deklariert mit uap10:TrustLevel="appContainer". Wird in der Regel in einem ressourcenschonenden App-Container ausgeführt (und daher mithilfe einer Dateisystem- und Registrierungsvirtualisierung isoliert). Weitere Informationen finden Sie unter MSIX-AppContainer-Apps.

Wichtig

Weitere Details, Abhängigkeiten und Funktionsanforderungen finden Sie in der Dokumentation zu diesen beiden Attributen unter Anwendung. Siehe auch uap10 wurde in Windows 10, Version 2004 (10.0; Build 19041) eingeführt.

Zweck von Verpackung und App-Container

Der Zweck der Verpackung der App besteht darin, ihr zur Laufzeit eine Paketidentität zu gewähren. Die Paketidentität wird für bestimmte Windows-Features benötigt (weitere Informationen finden Sie unter Features, für die eine Paketidentität benötigt wird). Sie können alle Kombinationen von oben beschriebenen App-Typen verpacken (und dadurch von der Paketidentität profitieren).

Ein wichtiges Ziel einer appContainer-App besteht jedoch darin, den App-Status vom Systemstatus bestmöglich zu trennen und dabei die Kompatibilität mit anderen Apps aufrechtzuerhalten. Windows erreicht dies, indem bestimmte Änderungen erkannt und umgeleitet werden, die es am Dateisystem und der Registrierung zur Laufzeit (als Virtualisierung bezeichnet) vorgibt. Wir werden darauf hinweisen, wenn ein Abschnitt nur für virtualisierte Apps gilt.

Installation

App-Pakete werden auf Benutzerbasis statt systemweit installiert. Der Standardspeicherort für neue Pakete auf einem neuen Computer befindet sich unter C:\Program Files\WindowsApps\<package_full_name>, wobei die ausführbare Datei app_name.exe heißt. Pakete können jedoch an anderen Orten installiert werden; bei den Startbefehlen von Visual Studio wird zum Beispiel das Verzeichnis $(OutDir) des Projekts verwendet.

Nach der Bereitstellung werden Paketdateien als schreibgeschützt markiert und vom Betriebssystem komplett gesperrt. Windows verhindert, dass Apps gestartet werden, wenn diese Dateien manipuliert werden.

Der Speicherort C:\Program Files\WindowsApps wird als PackageVolume bezeichnet. Dieser Speicherort ist das standardmäßige PackageVolume, mit dem Windows ausgeliefert wird; PackageVolumes können jedoch auf jedem Laufwerk und unter jedem Pfad erstellt werden. Darüber hinaus werden nicht alle Pakete in einem PackageVolume installiert (siehe Visual-Studio-Beispiel oben).

Dateisystem

Abhängig vom Speicherort des Ordners unterstützt das Betriebssystem verschiedene Ebenen von Dateisystemvorgängen für verpackte Desktop-Apps.

Für Ihr Gerät optimiert

Zur Vermeidung duplizierter Dateien (um den Speicherplatz auf dem Datenträger zu optimieren und die erforderliche Bandbreite beim Herunterladen von Dateien zu reduzieren) nutzt das Betriebssystem einen einzelnen Speicher und eine feste Verknüpfung von Dateien. Wenn ein MSIX-Paket heruntergeladen wird, wird anhand der Datei AppxManifest.xml bestimmt, ob die im Paket enthaltenen Daten bereits von einer früheren Paketinstallation auf dem Datenträger vorhanden sind. Ist dieselbe Datei in mehreren MSIX-Paketen vorhanden, speichert das Betriebssystem die gemeinsam verwendete Datei nur einmal auf dem Datenträger und erstellt feste Links von beiden Paketen zu dieser Datei. Da Dateien in 64-KB-Blöcken heruntergeladen werden, wird selbst dann, wenn ein Teil einer heruntergeladenen Datei auf dem Datenträger vorhanden ist, nur das abweichende Inkrement heruntergeladen. Dadurch wird die zum Herunterladen in Anspruch genommene Bandbreite reduziert.

AppData-Vorgänge unter Windows 10, Version 1903 und höher

Dieser Abschnitt gilt nur für virtualisierte Apps.

Alle neu erstellten Dateien und Ordner im Ordner AppData des Benutzers (zum Beispiel C:\Users\<user_name>\AppData) werden an einen privaten Speicherort für den Benutzer und die App geschrieben. Zur Laufzeit werden sie jedoch zusammengeführt, damit sie am tatsächlichen AppData-Speicherort erscheinen. Auf diese Weise kann ein gewisser Grad an Statustrennung für Artefakte erreicht werden, die nur von der App selbst verwendet werden. So kann das System diese Dateien bei der Deinstallation der App bereinigen.

Änderungen an vorhandenen Dateien im Ordner AppData des Benutzers sind zulässig, um einen höheren Grad an Kompatibilität und Interaktivität zwischen Apps und Betriebssystem zu erreichen. Das entlastet das System, da das Betriebssystem von jeder Datei- oder Verzeichnisänderung, die von einer App vorgenommen wird, Kenntnis hat. Durch die Statustrennung können zudem verpackte Desktop-Apps dort weitermachen, wo eine nicht verpackte Version derselben App aufgehört hat. Es ist zu beachten, dass das Betriebssystem keinen Ordner des virtuellen Dateisystems für den Ordner AppData des Benutzers unterstützt.

AppData-Vorgänge unter Windows 10 vor Version 1903

Dieser Abschnitt gilt nur für virtualisierte Apps.

Alle Schreibvorgänge im Ordner AppData des Benutzers (z. B. C:\Users\<user_name>\AppData), darunter Erstellungs-, Lösch- und Aktualisierungsvorgänge, werden beim Schreibvorgang an einen privaten Speicherort für den Benutzer und die App kopiert. So entsteht der Eindruck, dass die verpackte App die realen AppData-Daten bearbeitet, während tatsächlich eine private Kopie geändert wird. Durch eine derartige Umleitung von Schreibvorgängen kann das System alle von der App vorgenommenen Dateiänderungen nachverfolgen. Dadurch kann das System diese Dateien bei der Deinstallation der App bereinigen und somit das System entlasten und die App-Deinstallation für den Benutzer vereinfachen.

Arbeitsverzeichnis und Anwendungsdateien

Dieser Abschnitt gilt nur für virtualisierte Apps.

Zusätzlich zur Umleitung von AppData werden die bekannten Windows-Ordner (System32, Program Files (x86) usw.) dynamisch mit den entsprechenden Verzeichnissen im App-Paket zusammengeführt. Jedes verpackte Paket enthält im Stammverzeichnis einen Ordner mit dem Namen VFS. Alle Lesevorgänge von Verzeichnissen oder Dateien im Verzeichnis VFS werden zur Laufzeit mit ihren jeweiligen nativen Gegenstücken zusammengeführt. Beispielsweise könnte eine App C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll als Teil des App-Pakets enthalten, die Datei schiene jedoch unter C:\Windows\System32\vc10.dll installiert zu sein. Das gewährleistet die Kompatibilität mit Desktop-Apps, die davon ausgehen, dass sich Dateien an Speicherorten ohne Pakete befinden.

Schreibvorgänge in Dateien/Ordner im App-Paket sind nicht zulässig. Schreibvorgänge in Dateien und Ordner, die nicht Teil des Pakets sind, werden vom Betriebssystem ignoriert und sind nur zulässig, wenn der Benutzer über entsprechende Berechtigungen verfügt.

Allgemeine Dateisystemvorgänge

Diese kurze Referenztabelle enthält allgemeine Dateisystemvorgänge und Informationen zur Verarbeitung durch das Betriebssystem.

Vorgang Ergebnis Beispiel
Lesen oder Aufzählen bekannter Windows-Dateien oder -Ordner Eine dynamische Zusammenführung von C:\Program Files\<package_full_name>\VFS\<well_known_folder> mit dem Gegenstück des lokalen Systems. Beim Lesen von C:\Windows\System32 wird der Inhalt von C:\Windows\System32 sowie der Inhalt von C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86 zurückgegeben.
Schreiben unter AppData Windows 10, Version 1903 und höher: Neue Dateien und Ordner, die unter den folgenden Verzeichnissen erstellt werden, werden an einen privaten Speicherort pro Benutzer und pro Paket weitergeleitet:
  • Lokal
  • Local\Microsoft
  • Roaming
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Start Menu\Programs
Als Reaktion auf einen Befehl zum Öffnen einer Datei öffnet das Betriebssystem die Datei zunächst von dem benutzer- und paketabhängigen Speicherort. Wenn dieser Speicherort nicht vorhanden ist, versucht das Betriebssystem, die Datei am realen AppData-Speicherort zu öffnen. Wird die Datei am realen AppData-Speicherort geöffnet, erfolgt keine Virtualisierung für diese Datei. Dateilöschungen unter AppData sind zulässig, wenn der Benutzer über entsprechende Berechtigungen verfügt.

Windows 10 vor Version 1903: Kopie bei Schreibvorgang an einen benutzer- und App-spezifischen Speicherort.

 AppData ist üblicherweise C:\Users\<user_name>\AppData.
Schreiben innerhalb des Pakets Nicht erlaubt. Das Paket ist schreibgeschützt. Schreibvorgänge unter C:\Program Files\WindowsApps\<package_full_name> sind nicht zulässig.
Schreiben außerhalb des Pakets Zulässig, wenn der Benutzer über entsprechende Berechtigungen verfügt. Ein Schreibvorgang in C:\Windows\System32\foo.dll ist zulässig, wenn das Paket nicht C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dll enthält und der Benutzer über entsprechende Berechtigungen verfügt.

Speicherorte für verpacktes VFS

Dieser Abschnitt gilt nur für virtualisierte Apps.

Diese Tabelle zeigt, wo Dateien, die als Teil des Pakets geliefert werden, auf dem System für die App überlagert werden. Die App geht davon aus, dass sich diese Dateien an den aufgeführten Systemspeicherorten befinden, während sie sich tatsächlich an den umgeleiteten Speicherorten unter C:\Program Files\WindowsApps\<package_full_name>\VFS befinden. Die FOLDERID-Speicherorte stammen von den KNOWNFOLDERID-Konstanten.

Systemstandort Umgeleiteter Speicherort (unter <package_root>]\VFS) Gültig für Architekturen
FOLDERID_SystemX86 SystemX86 x86, amd64
FOLDERID_System SystemX64 amd64
FOLDERID_ProgramFilesX86 ProgramFilesX86 x86, amd6
FOLDERID_ProgramFilesX64 ProgramFilesX64 amd64
FOLDERID_ProgramFilesCommonX86 ProgramFilesCommonX86 x86, amd64
FOLDERID_ProgramFilesCommonX64 ProgramFilesCommonX64 amd64
FOLDERID_Windows Windows x86, amd64
FOLDERID_ProgramData Allgemeine AppData x86, amd64
FOLDERID_System\catroot AppVSystem32Catroot x86, amd64
FOLDERID_System\catroot2 AppVSystem32Catroot2 x86, amd64
FOLDERID_System\drivers\etc AppVSystem32DriversEtc x86, amd64
FOLDERID_System\driverstore AppVSystem32Driverstore x86, amd64
FOLDERID_System\logfiles AppVSystem32Logfiles x86, amd64
FOLDERID_System\spool AppVSystem32Spool x86, amd64

Registrierung

Dieser Abschnitt (und die Unterabschnitte) gelten nur für virtualisierte Apps.

App-Pakete enthalten eine Datei namens registry.dat, die als logische (virtuelle) Entsprechung von HKLM\Software in der realen Registrierung dient. Zur Laufzeit führt die virtuelle Registrierung den Inhalt dieser Struktur mit der nativen Systemstruktur zusammen, um eine einzelne Ansicht von beidem bereitzustellen. Wenn registry.dat z. B. einen einzelnen Schlüssel Foo enthält, enthält ein Lesevorgang von HKLM\Software zur Laufzeit scheinbar auch Foo (zusätzlich zu allen nativen Systemschlüsseln).

Zwar enthalten MSIX-Pakete HKLM- und HKCU-Schlüssel, sie werden aber unterschiedlich behandelt. Nur Schlüssel unter HKLM\Software sind Teil des Pakets. Schlüssel unter HKCU oder andere Teile der Registrierung sind es nicht. Schreibvorgänge für Schlüssel oder Werte im Paket sind nicht zulässig. Schreibvorgänge für Schlüssel oder Werte, die nicht Teil des Pakets sind, sind nur zulässig, wenn der Benutzer über entsprechende Berechtigungen verfügt.

Alle Schreibvorgänge unter HKCU werden beim Schreibvorgang an einen privaten Speicherort für den Benutzer und die App kopiert. In der Regel können Deinstallationsprogramme HKEY_CURRENT_USER nicht bereinigen, da die Registrierungsdaten für abgemeldete Benutzer nicht eingebunden und nicht verfügbar sind.

Alle Schreibvorgänge werden während der Paketaktualisierung beibehalten und nur gelöscht, wenn die App vollständig entfernt wird.

Allgemeine Registrierungsvorgänge

Der Großteil dieses Abschnitts gilt nur für virtualisierte Apps.

Diese kurze Referenztabelle enthält allgemeine Registrierungsvorgänge und Informationen zur Verarbeitung durch das Betriebssystem.

Vorgang Ergebnis Beispiel
Lesen oder Aufzählen von HKLM\Software Eine dynamische Zusammenführung der Paketstruktur mit dem Gegenstück des lokalen Systems. Wenn registry.dat einen einzelnen Schlüssel Foo enthält, zeigt zur Laufzeit ein Lesevorgang von HKLM\Software den Inhalt von HKLM\Software und HKLM\Software\Foo an.
Schreibvorgänge unter HKCU Werden beim Schreibvorgang an einen privaten Speicherort für den Benutzer und die App kopiert. Identisch mit AppData für Dateien.
Schreibvorgänge innerhalb des Pakets. Nicht erlaubt. Das Paket ist schreibgeschützt. Schreibvorgänge unter HKLM\Software sind nicht zulässig, wenn in der Paketstruktur ein entsprechender Schlüssel/Wert vorhanden ist.
Schreibvorgänge außerhalb des Pakets Vom Betriebssystem ignoriert. Zulässig, wenn der Benutzer über entsprechende Berechtigungen verfügt. Schreibvorgänge unter HKLM sind zulässig, solange kein entsprechender Schlüssel/Wert in der Paketstruktur vorhanden ist und der Benutzer über die richtigen Zugriffsberechtigungen verfügt.

Deinstallation

Dieser Abschnitt gilt nur für virtualisierte Apps.

Wenn ein Paket vom Benutzer deinstalliert wird, werden alle Dateien und Ordner unter C:\Program Files\WindowsApps\<package_full_name> sowie alle umgeleiteten Schreibvorgänge in AppData oder die Registrierung entfernt, die während des Verpackungsprozesses aufgezeichnet wurden.