Comprendre la façon dont les applications de bureau empaquetées s’exécutent sur Windows
Cette rubrique décrit les types d’applications de bureau que vous pouvez créer un package d’application Windows pour, ainsi que certains comportements de système d’exploitation (OS) et d’autres spécificités, qui sont importants à prendre en compte. Nous allons entrer dans les détails des éléments suivants (comme nous le verrons, le comportement spécifique dépend du type de votre application) :
- L’emplacement d’installation et le répertoire de travail de votre application (qui peuvent être différents de ce que votre application a supposé dans le passé).
- Le système de fichiers et le comportement du registre du système d’exploitation.
- Désinstallation.
Types d’applications de bureau
Il existe deux types d’application de bureau que vous pouvez créer et empaqueter. Vous déclarez le type de votre application dans son manifeste de package d’application à l’aide de l’attribut uap10 :RuntimeBehavior de l’élément Application :
- Un type inclut à la fois les applications WinUI 3 (qui utilisent le Kit de développement logiciel (SDK) d’application Windows) et les applications Pont du bureau (Centennial). Déclaré avec
uap10:RuntimeBehavior="packagedClassicApp". - L’autre type représente d’autres types d’application Win32, notamment les applications empaquetées avec un emplacement externe. Déclaré avec
uap10:RuntimeBehavior="win32App".
les applicationsuap10:RuntimeBehavior="windowsApp" plateforme Windows universelle (UWP) sont également empaquetées, mais cette rubrique ne les concerne pas.
Ensuite, l’attribut uap10 :TrustLevel (du même élément Application ) détermine si le processus de votre application empaquetée s’exécute à l’intérieur d’un conteneur d’applications.
- Une application de confiance totale. Déclaré avec
uap10:TrustLevel="mediumIL". - Application appContainer . Déclaré avec
uap10:TrustLevel="appContainer". S’exécute à l’intérieur d’un conteneur d’application léger (et est isolé à l’aide du système de fichiers et de la virtualisation du Registre). Pour plus d’informations, consultez les applications MSIX appContainer.
Important
Pour plus d’informations, des dépendances et des exigences de capacité, consultez la documentation relative à ces deux attributs dans Application. Voir également que uap10 a été introduit dans Windows 10, version 2004 (10.0 ; Build 19041).
Objectif de l’empaquetage et des conteneurs d’applications
L’objectif de l’empaquetage de votre application consiste à lui accorder une identité de package au moment du runtime. L’identité du package est nécessaire pour certaines fonctionnalités Windows, (voir Fonctionnalités nécessitant une identité de package). Vous pouvez empaqueter toutes les combinaisons de types d’applications décrits ci-dessus (et ainsi tirer parti de l’identité du package).
L’un des principaux objectifs de l’application appContainer est de séparer autant que possible l’état de l’application de l’état du système, tout en conservant la compatibilité avec les autres applications. Windows accomplit cela en détectant et en redirigeant certaines modifications qu’il apporte au système de fichiers et au Registre au moment de l’exécution (un processus appelé virtualisation). Nous allons appeler lorsqu’une section s’applique uniquement aux applications virtualisées.
Installation
Les packages de l’application sont installés par utilisateur plutôt qu’à l’échelle du système. L’emplacement par défaut des nouveaux packages sur un nouvel ordinateur est sous C:\Program Files\WindowsApps\<package_full_name>, avec l’exécutable nommé app_name.exe. Toutefois, les packages peuvent être installés dans d’autres emplacements ; par exemple, les commandes Start de Visual Studio utilisent les commandes du $(OutDir) projet .
Après le déploiement, les fichiers du package sont marqués en lecture seule et fortement verrouillés par le système d’exploitation (SE). Windows empêche le lancement des applications si ces fichiers sont falsifiés.
L’emplacement C:\Program Files\WindowsApps est ce qu’on appelle PackageVolume. Cet emplacement est le PackageVolume par défaut avec lequel Windows est fourni ; mais vous pouvez créer un PackageVolume sur n’importe quel lecteur et à n’importe quel chemin. En outre, tous les packages ne sont pas installés dans un PackageVolume (voir l’exemple Visual Studio ci-dessus).
Système de fichiers
Le système d’exploitation prend en charge différents niveaux d’opérations de système de fichiers pour les applications de bureau empaquetées, en fonction de l’emplacement du dossier.
Optimisation pour votre appareil
Afin d’éviter la duplication des fichiers pour optimiser l’espace de stockage sur disque et réduire la bande passante nécessaire lors du téléchargement de fichiers, le système d’exploitation tire parti du stockage unique et de l’établissement du lien physique des fichiers. Lorsqu’un utilisateur télécharge un package MSIX, AppxManifest.xml est utilisé pour déterminer si les données contenues dans le package existent déjà sur le disque depuis une installation de package antérieure. Si le même fichier existe dans plusieurs packages MSIX, le système d’exploitation ne stocke le fichier partagé sur le disque qu’une seule fois et crée des liens physiques entre les deux packages et le fichier partagé. Étant donné que les fichiers sont téléchargés dans des blocs de 64 Ko, même si un pourcentage d’un fichier en cours de téléchargement existe sur le disque, seul l’incrément qui est différent est téléchargé. Cela réduit la bande passante utilisée pour le téléchargement.
Opérations AppData sur Windows 10, version 1903 et ultérieures
Cette section s’applique uniquement aux applications virtualisées.
Tous les fichiers et dossiers nouvellement créés dans le dossier AppData de l’utilisateur (par exemple, C:\Users\<user_name>\AppData) sont écrits dans un emplacement privé par utilisateur et par application, mais fusionnés au moment du runtime pour s’afficher à l’emplacement AppData réel. Cela procure un certain degré de séparation des états pour les artefacts utilisés uniquement par l’application elle-même, et permet au système de nettoyer ces fichiers quand l’application est désinstallée.
Les modifications apportées aux fichiers existants dans le dossier AppData de l’utilisateur sont autorisées afin de fournir un degré plus élevé de compatibilité et d’interactivité entre les applications et le système d’exploitation. Cela permet de réduire la « détérioration » du système, car le système d’exploitation est conscient de chaque modification de fichier ou d’annuaire effectuée par une application. La séparation des états permet également aux applications de bureau empaquetées de reprendre là où une version non empaquetée de la même application s’est arrêtée. Notez que le système d’exploitation ne prend pas en charge les dossiers de système de fichiers virtuel comme dossiers AppData de l’utilisateur.
Opérations AppData sur Windows 10, version 1903 et antérieures
Cette section s’applique uniquement aux applications virtualisées.
Toutes les écritures effectuées dans le dossier AppData de l’utilisateur (par exemple, C:\Users\<user_name>\AppData), y compris la création, la suppression et la mise à jour, sont copiées au moment de l’écriture dans un emplacement privé par utilisateur et par application. Cela crée l’illusion que l’application packagée modifie le vrai dossier AppData, alors qu’elle modifie en fait une copie privée. En redirigeant les écritures de cette façon, le système peut suivre toutes les modifications de fichier effectuées par l’application. Cela permet au système de nettoyer ces fichiers quand l’application est désinstallée, réduisant ainsi la « détérioration » du système et fournissant une meilleure expérience de suppression d’application à l’utilisateur.
Répertoire de travail et fichiers d’application
Cette section s’applique uniquement aux applications virtualisées.
En plus de la redirection d’AppData, les dossiers bien connus de Windows (System32, Program Files (x86), et ainsi de suite.) sont fusionnés dynamiquement avec les répertoires correspondants dans le package de l’application. Chaque package contient un dossier nommé « VFS » à sa racine. Toutes les lectures d’annuaires ou de fichiers de l’annuaire VFS sont fusionnées au moment du runtime avec leurs équivalents natifs respectifs. Par exemple, une application peut contenir C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll dans le cadre de son package d’application, mais le fichier semble être installé sur C:\Windows\System32\vc10.dll. Cela permet d’assurer la compatibilité avec les applications de bureau qui s’attendent à trouver les fichiers ailleurs que dans les packages.
Les écritures dans les fichiers/dossiers du package d’application ne sont pas autorisées. Les écritures dans les fichiers et dossiers qui ne font pas partie du package sont ignorées par le système d’exploitation, et sont autorisées si l’utilisateur a une autorisation.
Opérations courantes du système de fichiers
Le petit tableau de référence suivant présente les opérations courantes du système de fichiers et la manière dont le système d’exploitation les gère.
| Opération | Résultats | Exemple |
|---|---|---|
| Lire ou énumérer un fichier ou un dossier Windows connu | Fusion dynamique de l’équivalent C:\Program Files\<package_full_name>\VFS\<well_known_folder> du système local. |
La lecture C:\Windows\System32 retourne le contenu de C:\Windows\System32 plus le contenu de C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86. |
Écrire sous AppData |
Windows 10, versions 1903 et ultérieures : Les fichiers et dossiers créés sous les répertoires suivants sont redirigés vers un emplacement privé par utilisateur et par package :
AppData réel. Si le fichier est ouvert à partir de l’emplacement AppData réel, aucune virtualisation de ce fichier ne se produit. Les suppressions de fichiers sous AppData sont autorisées si l’utilisateur dispose d’autorisations.Avant Windows 10, version 1903 : copie pour écriture dans un emplacement par utilisateur et par application. |
AppData est généralement C:\Users\<user_name>\AppData. |
| Écrire dans le package | Non autorisé. Le package est en lecture seule. | Les écritures sous C:\Program Files\WindowsApps\<package_full_name> ne sont pas autorisées. |
| Écrire en dehors du package | Autorisé si l’utilisateur dispose d’autorisations. | Une écriture est C:\Windows\System32\foo.dll autorisée si le package ne contient C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dll pas et que l’utilisateur dispose d’autorisations. |
Emplacements VFS empaquetés
Cette section s’applique uniquement aux applications virtualisées.
Ce tableau indique où les fichiers d’expédition dans le cadre de votre package sont superposés sur le système de l’application. Votre application détectera ces fichiers comme se trouvant aux emplacements système répertoriés, alors qu’en réalité ils se trouvent aux emplacements redirigés dans C:\Program Files\WindowsApps\<package_full_name>\VFS. Les emplacements FOLDERID proviennent des constantes KNOWNFOLDERID.
| Emplacement système | Emplacement redirigé (sous [<package_root>]\VFS) | Valide sur les architectures |
|---|---|---|
| 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 | AppData courant |
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 |
Registre
Cette section (et ses sous-sections) s’applique uniquement aux applications virtualisées.
Les packages d’application contiennent un fichier registry.dat, qui est l’équivalent logique (virtuel) de HKLM\Software dans le vrai Registre. Au moment du runtime, ce registre virtuel fusionne le contenu de cette ruche dans la ruche système native pour fournir une seule vue des deux. Par exemple, si registry.dat contient une seule clé Foo, une lecture de HKLM\Software au moment du runtime semble également contenir Foo (en plus de toutes les clés système natives).
Bien que les packages MSIX incluent des clés HKLM et HKCU, ils sont traités différemment. Seules les clés sous HKLM\Software font partie du package ; les clés sous HKCU ou d’autres parties du Registre ne le sont pas. Les écritures dans les clés ou les valeurs du package ne sont pas autorisées. Les écritures dans les clés ou les valeurs qui ne font pas partie du package sont autorisées dans la mesure où l’utilisateur a une autorisation.
Toutes les écritures sous HKCU sont copiées en écriture dans un emplacement privé par utilisateur et par application. Traditionnellement, les désinstalleurs ne peuvent pas propre HKEY_CURRENT_USER, car les données du Registre pour les utilisateurs déconnectés ne sont pas montées et indisponibles.
Toutes les écritures sont conservées pendant la mise à niveau du package et supprimées seulement quand l’application est entièrement supprimée.
Opérations courantes de Registre
La majorité de cette section s’applique uniquement aux applications virtualisées.
Le petit tableau de référence suivant présente les opérations courantes du Registre et la manière dont le système d’exploitation les gère.
| Opération | Résultats | Exemple |
|---|---|---|
| Lire ou énumérer HKLM\Software | Fusion dynamique de la ruche de package avec l’équivalent du système local. | Si registry.dat contient une seule clé Foo, au moment du runtime, une lecture de HKLM\Software affiche le contenu de HKLM\Software et HKLM\Software\Foo. |
| Écritures sous HKCU | Copié en écriture dans un emplacement privé par utilisateur et par application. | Identique à celui AppData des fichiers. |
| Écrit à l’intérieur du package. | Non autorisé. Le package est en lecture seule. | Les écritures sous HKLM\Software ne sont pas autorisées si une clé/valeur correspondante existe dans la ruche du package. |
| Écritures en dehors du package | Ignoré par le système d’exploitation. Autorisé si l’utilisateur dispose d’autorisations. | Les écritures sous HKLM\Software sont autorisées tant qu’il n’existe pas une paire clé/valeur correspondante dans la ruche du package et que l’utilisateur dispose des autorisations d’accès appropriées. |
Désinstallation
Cette section s’applique uniquement aux applications virtualisées.
Quand l’utilisateur désinstalle un package, tous les fichiers et dossiers situés dans C:\Program Files\WindowsApps\<package_full_name> sont supprimés, ainsi que les écritures redirigées vers AppData ou le registre capturées durant le processus d’empaquetage.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour