Windows Dev Center

Informations
Le sujet que vous avez demandé est indiqué ci-dessous. Toutefois, ce sujet ne figure pas dans la bibliothèque.

Packages et déploiement d’applications (applications Windows Runtime)

En tant que développeur, vous n’écrivez pas de routines pour installer ou désinstaller votre application Windows Runtime. En revanche, vous empaquetez votre application et la soumettez au Windows Store. Les utilisateurs achètent votre application sur le Windows Store sous forme de package d’application. Le système d’exploitation utilise les informations contenues dans un package d’application pour installer l’application et s’assurer que toutes les traces de l’application sont supprimées de l’appareil une fois que l’utilisateur l’a désinstallée.

Un package d’application est un conteneur basé sur la norme OPC (Open Packing Conventions). OPC définit un méthode de stockage structurée des données et des ressources de l’application basée sur un fichier ZIP standard. Pour obtenir des informations sur l’utilisation de Microsoft Visual Studio pour déployer des packages d’application, voir Déploiement de vos applications Windows Runtime depuis Visual Studio.

À partir de Windows 8.1 et Windows Phone 8.1, les nouvelles offres groupées d’applications permettent d’optimiser l’empaquetage et la distribution d’une application. En outre, les packs de ressources vous permettent de proposer des suppléments, tels qu’une traduction ou les ressources requises pour des écrans haute résolution, aux clients qui le souhaitent, sans affecter l’espace disque, la bande passante ni l’expérience d’achat de l’application pour les utilisateurs qui ne le souhaitent pas. Par ailleurs, la création de liens physiques optimise l’installation de votre application en éliminant les données dupliquées résultant du téléchargement du même fichier à plusieurs reprises.

Déploiement d’applications Windows Runtime

Le modèle d’application Windows Runtime est un processus piloté par les états déclaratif qui fournit toutes les données et instructions d’installation et de mise à jour pour une application dans un seul package. Dans ce modèle déclaratif, les opérations de déploiement sont fiables. Les fichiers livrés dans le package sont inaltérables, ce qui signifie qu’ils n’ont pas été modifiés depuis qu’ils ont été transmis à l’appareil. Dans la mesure où le propriétaire du package n’a pas besoin d’écrire des actions et du code personnalisés, le nombre de points d’échec est réduit.

Pendant le processus de mise à jour, une nouvelle version de l’application est téléchargée et installée dans le profil de l’utilisateur ; juste après, l’ancienne version est supprimée de l’appareil. Contrairement à Windows Installer, il n’existe pas de concept de fichiers de correctifs ou d’autres fichiers utilisés pour déployer une application Windows Runtime.

Remarque  

Sous Windows, comme les applications Windows Runtime sont installées dans le profil d’un utilisateur, chaque utilisateur dispose d’un contrôle total sur ses applications du Windows Store. Les applications peuvent être installées, mises à jour et supprimées sans affecter les applications d’aucun autre utilisateur sur l’appareil.

Pour plus d’informations sur le déploiement, voir Déploiement pour les applications du Windows Runtime.

Packages d’application Windows Runtime – .appx

Tous les composants qui définissent une application Windows Runtime sont stockés dans un package d’application Windows Runtime. Ce package d’application Windows Runtime comprend une extension de fichier .appx et représente l’unité d’installation pour une application Windows Runtime. Les packages d’application Windows Runtime sont des fichiers de conteneur ZIP qui sont définis comme un sous-ensemble des normes ISO et OPC (Open Packaging Conventions) ECMA. Chaque package d’application Windows Runtime contient les fichiers de charge utile de l’application ainsi que les informations nécessaires pour valider, déployer, gérer et mettre à jour l’application. De manière globale, chaque package d’application Windows Runtime contient les éléments suivants :

Charge utile de l’application

Ressources et fichiers du code d’application

Les fichiers de charge utile sont les ressources et fichiers de code que vous produisez lorsque vous créez votre application Windows Runtime.

Manifeste de l’application

Fichier manifeste de l’application (Package.appxmanifest)

Le manifeste de l’application déclare l’identité de l’application, ses fonctionnalités et des informations pour le déploiement et la mise à jour. Pour plus d’informations sur le fichier manifeste de l’application, voir Manifeste du package d’application.

Mappage de bloc de l’application

Fichier de mappage de bloc du package d’application (AppxBlockMap.xml)

Le fichier de mappage de bloc répertorie tous les fichiers d’application contenus dans le package avec les valeurs de hachage de chiffrement associées que le système d’exploitation utilise pour valider l’intégrité des fichiers et optimiser une mise à jour pour l’application. Pour plus d’informations sur le fichier de mappage de bloc, voir Mappage de bloc du package de l’application.

Signature d’application

Fichier de signature numérique du package d’application (AppxSignature.p7x)

La signature du package d’application garantit que le package et son contenu n’ont pas été modifiés après avoir été signés. Si le certificat de signature est validé en certificat Autorités de certification racines de confiance, la signature identifie également le signataire du package. Le signataire du package est généralement l’auteur ou l’éditeur de l’application.

Ces éléments qui précèdent comprennent une application Windows Runtime entièrement autonome qui peut être déployée vers Windows 8 et versions ultérieures, ainsi que vers Windows Phone 8.1 et versions ultérieures. Vous créez la charge utile de l’application et les fichiers manifeste pour votre application. Lorsque Visual Studio empaquette votre application, il ajoute automatiquement les fichiers de signature et de mappage de bloc de l’application au package. Toutefois, vous pouvez également employer les utilitaires MakeAppx et SignTool autonomes si vous voulez empaqueter manuellement votre application. Ces sections décrivent comment empaqueter et déployer les applications Windows Runtime.

Identité du package

L’un des éléments les plus fondamentaux du package d’application est le tuple en 5 parties qui définit le package. Ce tuple est connu sous le nom d’identité du package et est constitué des données suivantes :

Name

Nom général utilisé pour le package d’application. Par exemple, "myCompany.mySuite.myApp".

Remarque  Ce nom n’est pas nécessairement le nom affiché sur la vignette d’application.
Publisher

L’éditeur fait référence à l’éditeur de l’application Windows Runtime. Dans la plupart des cas, l’éditeur est le même que le compte utilisé pour l’inscription à un compte de développeur.

Version

Descripteur de version en quatre parties (major.minor.build.revision) qui est utilisé pour traiter les futures versions de l’application. Par exemple, "1.0.0.0".

Remarque  Vous devez utiliser les quatre parties du descripteur de version.
ProcessorArchitecture

Architecture cible du package d’application. Cette valeur peut être "x86", "x64", "arm" ou "neutre". Dans de nombreux cas, ce champ peut être "neutre" pour représenter toutes les architectures.

ResourceID

Facultatif.

Chaîne spécifiée par l’éditeur qui indique les ressources du package d’application. Cette partie du tuple est utilisée principalement si le package d’application a des ressources qui sont spécifiques à une région, telles que les langues.

Si vous créez le package manuellement, voir l’élément Identity.

Format des packages

Nous décrivons ici des détails relatifs aux packages d’application, c’est-à-dire le format de fichier .appx.

Les packages d’application sont en lecture seule

Même si les packages d’application sont basés sur un sous-ensemble de la norme OPC, nous vous déconseillons d’utiliser des API existantes pour la manipulation des fichiers OPC ou ZIP afin de modifier les packages d’application. Après avoir créé un package d’application, traitez le package comme étant en lecture seule. Les processus Visual Studio et MakeAppx qui créent des packages d’application génèrent le fichier AppxBlockMap.xml et l’ajoutent au package automatiquement. Si vous modifiez le contenu du package, vous devez mettre à jour le fichier de mappage de bloc du package en conséquence. Pour créer un package et un fichier de mappage de bloc, vous devez régénérer le package avec Visual Studio, la commande de compression MakeAppx ou les API IAppxPackageWriter de code natif Windows 8.

Noms des fichiers de charge utile du package d’application

Pour être conformes à la norme OPC, les noms des chemins d’accès de tous les fichiers qui sont stockés dans un package d’application doivent être compatibles URI (Uniform Resource Identifier). Les chemins d’accès aux fichiers qui ne sont pas compatibles URI doivent être codés en pourcentage lorsqu’ils sont stockés dans un package d’application, puis à nouveau décodés dans le chemin d’accès au fichier d’origine lorsqu’ils sont extraits du package. Prenons l’exemple du fichier de charge utile suivant avec un chemin d’accès et un nom qui contient des espaces incorporés et des caractères réservés à l’URI « [ » et « ] » :


\my pictures\kids party[3].jpg

Lorsque vous stockez ce fichier de charge utile dans le package d’application, le chemin d’accès du fichier devient :


/my%20pictures/kids%20party%5B3%5D.jpg

Visual Studio, l’outil de création de package de l’application (MakeAppx), et les API de création de packages gèrent le codage et le décodage en pourcentage des chemins d’accès aux fichiers automatiquement. Si vous tentez d’extraire des fichiers directement à partir d’un package d’application à l’aide d’API ou d’utilitaires ZIP généraux, les chemins d’accès aux fichiers peuvent rester codés en pourcentage. Nous vous conseillons donc d’extraire les fichiers d’un package d’application à l’aide de la commande de décompression MakeAppx ou des API IAppxPackageReader.

Capacités du package d’application

Les packages d’application prennent en charge les applications avec les limites de capacité suivantes :

Capacité du packageMaximum
Nombre de fichiers100 000 fichiers
Taille de package100 Go

 

Noms de fichiers et de chemins d’accès réservés du package d’application

Ces noms de fichiers et de chemins d’accès étant réservés, ne les utilisez pas pour les fichiers de charge utile de l’application :

Noms de fichiers et de chemins d’accès réservésUtilisation
/Package.appxmanifestNom de fichier réservé pour le manifeste du package d’application créé par le développeur
/AppxBlockMap.xmlNom de fichier réservé pour le mappage de bloc du package d’application
/AppxSignature.p7xNom de fichier réservé pour la signature numérique Microsoft Authenticode du package d’application
/[Content_Types].xmlNom de fichier réservé pour les métadonnées des types de contenus requises par la norme OPC pour le package d’application
/AppxMetadata/Chemin d’accès au dossier réservé pour les fichiers de métadonnées du package d’application
/Microsoft.System.Package.Metadata/Chemin d’accès au dossier réservé pour les fichiers de métadonnées Microsoft sur les packages d’application déployés

 

Signatures numériques du package d’application

Vous devez signer chaque package d’application avant que les utilisateurs puissent les installer. Alors que la signature des packages d’application est en partie automatisée via Authenticode, vous devez contrôler les fonctionnalités suivantes lorsque vous signez des packages d’application :

  • Le nom du sujet du certificat de signature de code doit correspondre à l’attribut Publisher qui est spécifié dans l’élément Identity du fichier AppxManifest.xml dans le package d’application.
  • L’algorithme de hachage qui est utilisé pour signer le package d’application doit correspondre à celui qui est utilisé pour générer le fichier AppxBlockMap.xml dans le package d’application. Cet algorithme de hachage est spécifié dans l’attribut HashMethod de l’élément BlockMap.
  • Un package d’application ne peut pas être horodaté indépendamment de la signature. Il doit être horodaté pendant la signature si l’enregistrement des informations de date est souhaité.
  • Les packages d’application ne prennent pas en charge plusieurs signatures enveloppées.

La signature d’un package détermine le mode de licence de l’application Windows Runtime. Le mode de licence d’une application affectant son mode d’installation et d’exécution, il est possible que deux packages d’application ayant la même identité ne soient pas traités de la même manière pendant l’installation. Par exemple, vous ne pouvez pas installer un package d’application avec la même identité de package qu’une autre application déjà installée, s’il ne possède pas également la même signature.

Installation déclarative

Le déploiement d’applications Windows Runtime est un processus entièrement déclaratif qui se base sur le manifeste du package d’application. Vous utilisez le manifeste du package d’application pour capturer l’intégration au système d’exploitation que vous souhaitez. Par exemple, vous utilisez le manifeste du package d’application pour déclarer le besoin d’utiliser une association de types de fichiers, comme .jpg, sur le système d’exploitation.

En procédant ainsi, le système d’exploitation peut entièrement gérer le processus du déploiement d’applications Windows Runtime pour offrir une expérience cohérente et fiable à chaque utilisateur sur de nombreux appareils. En outre, en ayant une application Windows Runtime avec installation déclarative, la désinstallation de l’application devient déterministe et renouvelable.

Dans le manifeste du package d’application, vous pouvez déclarer une large gamme de technologies dans le cadre de l’installation d’une application Windows Runtime.

Conditions requises pour l’application:  

Pour déployer correctement une application, le système d’exploitation doit répondre à l’ensemble des conditions requises pour cette application qui sont référencées dans le manifeste du package d’application. Par exemple, si une version du système d’exploitation expose une nouvelle API qu’une application Windows Runtime appelle, l’application déclare une condition requise sur le système d’exploitation avec cette version minimale spécifique. Dans ce cas, le système d’exploitation approprié doit être présent sur l’appareil cible avant de pouvoir installer l’application. Dans Windows 8 et versions ultérieures et dans Windows Phone 8.1 et versions ultérieures, vous pouvez déclarer ces types clés de conditions requises dans le manifeste du package d’application :

OSMinVersion

Spécifie la version minimale du système d’exploitation ainsi que la plateforme de modèle d’applications où l’exécution de cette application est autorisée.

OSMaxVersionTested

Spécifie la version maximale du système d’exploitation où cette application a été testée par le développeur et identifiée comme étant dans un état actif. Ce champ de conditions requises est utilisé par le système d’exploitation pour déterminer si un problème de compatibilité des applications pourrait survenir pendant l’utilisation de l’application. Par exemple, si l’application appelle une API du Kit de développement logiciel (SDK) Windows 8 et que l’API a été par la suite modifiée dans une version suivante du système d’exploitation, l’application peut se comporter de façon incorrecte. Ce champ de conditions requises permet de garantir que le système d’exploitation peut identifier et corriger ce comportement afin que l’application continue de fonctionner sur toutes les versions suivantes du système d’exploitation.

Fonctionnalités

Les applications Windows Runtime qui ont besoin d’un accès par programme à des ressources utilisateur telles que des images ou à des périphériques connectés tels qu’une webcam doivent déclarer la fonctionnalité appropriée. Une application demande un accès en déclarant les fonctionnalités dans son manifeste du package d’application. Vous pouvez déclarer les fonctionnalités à l’aide du concepteur de manifeste dans Visual Studio, ou vous pouvez les ajouter manuellement au manifeste de package comme cela est décrit dans Comment spécifier des fonctionnalités dans un manifeste de package. Pour plus d’informations sur les fonctionnalités, voir Déclarations des fonctionnalités d’application.

Dépendances:  

Le Windows Store héberge un ensemble unique de packages d’application qui contiennent des composants de système d’exploitation qui fonctionnent indépendamment du système d’exploitation. Les applications Windows Runtime peuvent utiliser ces packages d’application en déclarant une dépendance dans leur manifeste du package d’application. Les composants contenus dans les packages d’application hébergés par le Store sont appelés bibliothèques de composants de système d’exploitation. Le Store gère le processus permettant de garantir la présence de la version appropriée de la bibliothèque de composants quand l’application est installée sur un appareil. Ces bibliothèques, notamment la bibliothèque Windows pour JavaScript, les bibliothèques Runtime C++ (CRT) et la gestion des droits numériques PlayReady, sont essentielles à la création des applications Windows Runtime. Quand une application est déployée à partir du Store, le système d’exploitation respecte la déclaration de dépendance en téléchargeant et en installant la bibliothèque de composants appropriée avec l’application qui est téléchargée depuis le Store.

Pour charger une version test des applications du Windows Store pour un déploiement de test ou d’entreprise, le package d’application de la bibliothèque de composants Windows doit être fourni et spécifié lors du déploiement du package d’application.

Offres groupées d’applications

À partir de Windows 8.1 et de Windows Phone 8.1, vous pouvez utiliser l’offre groupée d’applications (ou package .appxbundle) pour optimiser la création de packages et la distribution d’une application Windows Runtime et de packages de ressources à des utilisateurs dans le monde entier.

Remarque  Créez une offre groupée d’applications pour toutes vos architectures plutôt que des offres groupées distinctes pour chaque architecture.

Vous créez la charge utile de l’offre groupée d’applications pour votre application. Visual Studio crée et ajoute le manifeste de l’offre groupée. Lorsque Visual Studio place votre application dans une offre groupée, il place automatiquement les ressources dans des packages distincts et ajoute les fichiers de signature et de mappage de bloc de l’application dans l’offre groupée. Les éléments suivants comprennent une application Windows Runtime entièrement autonome qui peut être déployée sur Windows 8.1 et Windows Phone 8.1.

Packages d’application (.appx)

L’offre groupée d’applications ne peut contenir plusieurs packages d’application que si chacun cible une architecture spécifique différente. Par exemple, elle peut contenir un package x86.appx et un package amd64.appx, mais pas deux packages amd64.appx.

Packages de ressources (.appx)

L’offre groupée d’applications contient des packages de ressources (fichiers .appx) pour les langues, l’échelle et les fonctionnalités Microsoft DirectX. Chaque offre groupée d’applications peut contenir de nombreux packages de ressources différents pour prendre en charge différentes configurations de périphériques. Quand vous référencez directement un package de ressources dans votre application Windows Runtime, nous vous recommandons de tirer pleinement parti du système de gestion des ressources.

Remarque  Les packages de ressources ne doivent jamais contenir de code.
Manifeste de l’offre groupée d’applications (AppxBundleManifest.xml)

Le manifeste de l’offre groupée d’applications (fichier .appxbundlemanifest) contient toutes les informations d’applicabilité concernant les packages inclus. Pour un package spécifique, il indique le type de package ("Application" ou "Ressource") plus la version et le ciblage de ressource. Spécifiquement pour les packages d’application, le manifeste de l’offre groupée d’applications contient des informations relatives à l’architecture.

En règle générale, le manifeste de l’offre groupée d’applications permet au modèle d’application de comprendre le contenu de l’offre groupée d’applications et de déterminer au moment de l’installation quel package d’application et quels packages de ressources installer sur l’appareil de l’utilisateur.

Voici un exemple d’un fichier manifeste d’offre groupée d’applications.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Bundle xmlns="http://schemas.microsoft.com/appx/2013/bundle" SchemaVersion="1.0">
  <Identity Name="Example" Publisher="CN=ExamplePublisher" Version="2013.101.312.1053"/>
  <Packages>
    <Package Type="application" Version="1.0.0.5" Architecture="x86" FileName="AppPackage_X86.appx" Offset="49" Size="3207">
      <Resources>
        <Resource Language="en-us"/>
        <Resource Scale="100" />
      </Resources>
    </Package>
    <Package Type="application" Version="1.0.0.4" Architecture="x64" FileName="AppPackage_X64.appx" Offset="3329" Size="3204">
      <Resources>
        <Resource Language="en-us"/>
        <Resource Scale="100" />
      </Resources>
    </Package>
    <Package Type="resource" Version="1.0.0.0" ResourceId="French" FileName="ResourcePackage_French.appx" Offset="6606" Size="1423">
      <Resources>
        <Resource Language="fr"/>
        <Resource Language="fr-fr"/>
        <Resource Language="fr-ca"/>
      </Resources>
    </Package>
    <Package Type="resource" Version="1.0.0.3" ResourceId="HiRes" FileName="ResourcePackage_HiRes.appx" Offset="8111" Size="1584">
      <Resources>
        <Resource Scale="140"/>
      </Resources>
    </Package>
  </Packages>
</Bundle>

Mappage de bloc de l’application (AppxBlockMap.xml)

Le fichier de mappage de bloc répertorie tous les fichiers contenus dans l’offre groupée (à l’exception des packages d’application et de ressource), avec les valeurs de hachage de chiffrement associées que le système d’exploitation utilise pour valider l’intégrité des fichiers et optimiser une mise à jour pour l’application. Pour plus d’informations sur le fichier de mappage de bloc, voir Mappage de bloc du package de l’application.

Signature de l’application (AppxSignature.p7x)

La signature de l’offre groupée d’applications garantit que le package et son contenu n’ont pas été modifiés après avoir été signés. Si le certificat de signature est validé en certificat Autorités de certification racines de confiance, la signature identifie également le signataire du package. Le signataire du package est généralement l’auteur ou l’éditeur de l’application.

Packages de ressources

À partir de Windows 8.1 et de Windows Phone 8.1, vous pouvez utiliser le package de ressources pour contenir des ressources supplémentaires pour l’application principale (par exemple, des éléments spécifiques au français, tels que des chaînes ou des images). En utilisant le package de ressource, vous pouvez séparer le package de l’application principal de ces ressources supplémentaires. Le package de ressources permet donc de personnaliser l’expérience globale de l’application sans nécessiter un téléchargement et une installation de tous les packages de ressources sur l’appareil.

Le package de ressources est facultatif et le package d’application ne doit pas en dépendre. Cela signifie que le package d’application doit contenir au moins un ensemble de ressources par défaut qui pourra toujours être utilisé si aucun package de ressources n’est installé sur l’appareil. Cela permet que les affirmations suivantes soient vraies :

  • le package d’application peut toujours être installé et démarré correctement sur n’importe quel appareil dépourvu de package de ressources ;

  • si le package de ressources installé n’est pas complet, le package d’application dispose de ressources de secours.

Le package de ressources a les fonctions suivantes dans le modèle d’application :

  • Il fournit des ressources candidates que le système de gestion des ressources peut utiliser au cours de l’exécution de l’application pour adapter l’expérience de l’application.

  • Il fournit des métadonnées qui permettent au package de ressources de cibler un qualificateur de ressources spécifique (par exemple, langue utilisateur, échelle système ou fonctionnalités DirectX).

Les packages de ressources peuvent cibler un seul qualificateur de ressources par package. Toutefois, votre application peut utiliser plusieurs packages de ressources.

Les packages de ressources ne doivent jamais contenir de code.

Liens physiques

Depuis Windows 8.1 et Windows Phone 8.1, lorsque le système d’exploitation installe votre application, il optimise l’installation en ne téléchargeant pas plusieurs fois le même fichier, dans la mesure du possible. Si le système d’exploitation détermine que votre application utilise un fichier qui a déjà été installé sur l’appareil, une version partagée de ce fichier est créée, et un lien physique est établi entre votre application et la version partagée. Cela permet de réduire le temps d’installation de l’application et l’espace qu’elle occupe sur le disque. Ces fichiers partagés peuvent être des bibliothèques, des runtimes, etc. Pour tirer parti des liens physiques, nous vous recommandons de suivre les meilleures pratiques. Par exemple, faites en sorte de réutiliser le plus possible les mêmes binaires de runtime ou de bibliothèque avec chaque version de votre application, sauf si vous devez absolument les mettre à jour.

Mise à jour Windows 8.1 :  Pour la version initiale de Windows 8.1, la création de liens physiques était limitée aux applications du Windows Store. Dans le cadre de la mise à jour de Windows 8.1, il est possible de créer des liens physiques dur dans les versions tests des applications d’entreprise. Pour plus d’informations sur le chargement de versions tests, voir Déploiement d’applications d’entreprise.

Déploiements par utilisateur

Remarque  

Les déploiements d’applications Windows Runtime s’effectuent par utilisateur, ce qui signifie qu’ils n’ont un impact que sur le compte de l’utilisateur qui les a installées. De plus, dans des scénarios à plusieurs utilisateurs, les utilisateurs ne savent pas ce qui a été installé pour les autres utilisateurs. Supposons par exemple que l’utilisateur UserA a installé l’application Bloc-notes alors que l’utilisateur UserB a installé l’application Calculatrice. Dans ce scénario, UserA et UserB n’ont aucune connaissance des autres applications installées sur le même ordinateur (isolation de l’application).

Isolation de l’application

Remarque  

L’isolation de l’application sur le système d’exploitation est limitée uniquement à la partie utilisateur de l’application Windows Runtime. Toutes les autres données de l’application sont stockées à un emplacement accessible au système d’exploitation. Supposons par exemple que l’utilisateur UserA a installé l’application Calculatrice et que l’utilisateur UserB a également installé l’application Calculatrice ; dans ce scénario, une seule copie des fichiers binaires de l’application Calculatrice est stockée sur le lecteur (%ProgramFiles%\WindowsApps), et les deux utilisateurs y ont accès. UserA ne voit pas les données d’application d’UserB, et vice versa. Alors que les fichiers binaires d’exécution sont partagés, les données d’application sont toujours isolées.

Il est impossible de modifier le répertoire %ProgramFiles%\WindowsApps. Cela comprend également le répertoire %ProgramFiles% sous-jacent ainsi que les répertoires %ProgramData% et %UserProfile%.

Existence de plusieurs versions

Remarque  

Le répertoire WindowsApps contient tous les fichiers binaires de l’application du Windows Store pour tous les utilisateurs du système, mais il peut également contenir plusieurs versions de la même application du Windows Store. Par exemple, supposons que les utilisateurs UserA et UserB ont tous deux installé l’application Bloc-notes, et qu’UserA a effectué la mise à jour vers la version 2 de l’application Bloc-notes, mais pas UserB. Dans ce scénario, deux versions de l’application Bloc-notes existent sur le système d’exploitation. Dans la mesure où une seule version est installée pour chaque utilisateur, les différentes versions ne sont pas en conflit entre elles.

Ce comportement est également applicable aux packages de dépendances.

Déploiement pour les applications Windows Runtime

Ces sections décrivent le déroulement de l’installation, de la mise à jour et de la suppression des applications Windows Runtime.

Installation des applications Windows Runtime

Cette figure illustre le déroulement de l’installation des applications Windows Runtime :

Déroulement de l’installation des applications du Windows Store

Le processus du déploiement des applications Windows Runtime se déroule en plusieurs étapes. Au départ, le système d’exploitation acquiert et valide le manifeste de l’application, le mappage de bloc de l’application et la signature de l’application. Ensuite, le système d’exploitation vérifie les critères de déploiement du package d’application pour assurer la réussite du déploiement de l’application. Le système d’exploitation effectue ensuite une copie intermédiaire des fichiers binaires du package dans le répertoire WindowsApps. Enfin, le système d’exploitation inscrit le package dans le compte de l’utilisateur.

Vérifications de déploiement (validation)

Cette figure illustre l’étape des vérifications du déploiement par le système d’exploitation :

Vérifications de la mise en place du déploiement

Une fois que l’utilisateur a démarré l’installation d’une application Windows Runtime, le système d’exploitation doit effectuer les vérifications suivantes avant que le processus de déploiement ne puisse commencer :

La version minimale du système d’exploitation doit être satisfaite

Vous indiquez les conditions requises pour l’application dans le manifeste du package d’application. Elles indiquent le besoin de satisfaire à une version du système d’exploitation minimale spécifique. Pour plus d’informations sur les conditions requises pour l’application, voir Conditions requises pour l’application.

Les dépendances de l’application doivent être satisfaites

Les applications Windows Runtime peuvent présenter une dépendance d’un autre package d’application pour des fonctionnalités supplémentaires nécessaires à l’application. Pour plus d’informations sur les dépendances des applications, voir Dépendances.

L’espace disque doit être suffisant

Chaque application Windows Runtime requiert la présence d’une certaine quantité d’espace disque pour pouvoir être déployée. Si l’espace disque n’est pas suffisant sur l’appareil pour déployer le package, le déploiement échoue.

L’application n’est pas déjà déployée

Dans le contexte de l’utilisateur spécifique qui a installé l’application Windows Runtime, l’application ne peut pas être à nouveau installée, et une vérification doit donc être effectuée pour déterminer si l’application n’est pas déjà installée.

Les ressources de l’application doivent satisfaire à la vérification de signature

En utilisant l’élément BlockMap déjà validé, l’intégrité de chaque fichier du package d’application doit être vérifiée.

Copie intermédiaire du package

Cette figure illustre l’étape de copie intermédiaire du package par le système d’exploitation :

Copie intermédiaire du package de déploiement

Une fois que le modèle d’application a déterminé que le package peut être déployé sur l’appareil, le système d’exploitation stocke le contenu du package sur le disque dans le répertoire %ProgramFiles%\WindowsApps dans un nouveau répertoire nommé d’après l’identité du package :


<Package Name>_<Version>_<Architecture>_<ResourceID>_<Publisher Hash>

Le processus de copie intermédiaire se déroule via un ensemble de demandes effectuées par le moteur de déploiement auprès de la source de l’emplacement du package. Ces demandes sont ensuite satisfaites par la source et retournées au moteur de déploiement où elles sont décompressées, validées par rapport à l’élément BlockMap, puis copiées dans le fichier approprié.

Inscription du package

Cette figure illustre l’étape d’inscription du package par le système d’exploitation :

Inscription du package de déploiement

L’inscription du package représente la dernière étape du processus de déploiement. Au cours de cette étape, les extensions qui sont déclarées dans le manifeste sont inscrites auprès du système d’exploitation. Cela permet à l’application de s’intégrer en profondeur au système d’exploitation. Par exemple, si vous voulez que votre application soit en mesure d’ouvrir des fichiers .txt, déclarez une extension FileTypeAssociation en tant que données XML dans votre manifeste du package d’application et indiquez .txt comme type de fichier. Au moment du déploiement, ces données XML sont converties en un ensemble de modifications apportées au système nécessaires pour inscrire correctement l’application afin de gérer des fichiers .txt. Ces modifications sont ainsi apportées pour le compte de l’application par le modèle d’application. Le modèle d’application prend en charge de nombreuses extensions différentes. Pour plus d’informations sur ces extensions, voir Contrats et extensions d’application.

Mise à jour des applications Windows Runtime

Cette figure illustre le déroulement de la mise à jour des applications Windows Runtime :

Mise à jour du déploiement

Le flux de travail de la mise à jour est identique à celui de l’étape Installation des applications Windows Runtime, mais voici quelques différences clés qui rendent la mise à jour unique.

Vérifications de déploiement pour la mise à jour

Cette figure illustre l’étape des vérifications du déploiement pour la mise à jour par le système d’exploitation :

Vérifications de la mise à jour du déploiement

Si la version du package d’application actuellement installée est supérieure ou égale à celle que l’utilisateur essaye d’installer, le déploiement échoue.

Copie intermédiaire du package (téléchargements différentiels)

Cette figure illustre l’étape de copie intermédiaire du package mis à jour par le système d’exploitation :

Copie intermédiaire de la mise à jour du déploiement

Le processus de copie intermédiaire pendant la mise à jour est semblable au processus de copie intermédiaire classique pendant l’installation. Toutefois, la différence clé réside dans le fait qu’une version préexistante du package est déjà installée sur le système d’exploitation. À la fin de l’installation du package préexistant, un ensemble de fichiers de charge utile sont téléchargés et copiés sur l’appareil. Dans de nombreux cas, un grand nombre de ces fichiers de charge utile ne seront pas modifiés ou ne le seront que très peu dans la version mise à jour du package d’application. Vous pouvez utiliser ces fichiers de charge utile pour construire les ressources et le contenu du package d’application mis à jour. Dans la mesure où la structure BlockMap du package d’application contient une liste de hachages pour chaque bloc de chaque fichier, le système d’exploitation peut calculer l’ensemble précis de modifications au niveau d’un bloc via une comparaison des anciens et nouveaux fichiers BlockMap d’application. Voici les résultats possibles de cette comparaison :

Un fichier n’a pas été modifié

Le fichier est lié physiquement à l’emplacement du dossier du package mis à jour.

Les blocs d’un fichier n’ont pas été modifiés

Les blocs non modifiés sont copiés sur le dossier du package mis à jour.

Les blocs du fichier ont été modifiés

Les blocs modifiés sont marqués pour être téléchargés depuis la source.

Un fichier entier est nouveau

L’intégralité du fichier sera téléchargée depuis la source.

Un fichier n’existe plus

Le fichier ne sera pas du tout utilisé pour la mise à jour.

Une fois la comparaison terminée, toutes les données qui peuvent être conservées sont liées physiquement ou copiées, et toutes les nouvelles données sont téléchargées depuis la source et utilisées pour créer les fichiers mis à jour.

Inscription du package pour la mise à jour

Cette figure illustre l’étape d’inscription du package mis à jour par le système d’exploitation :

Inscription du package mis à jour de déploiement

Quand vous mettez à jour l’inscription d’un package, le système d’exploitation doit également mettre à jour les inscriptions des versions antérieures. Le modèle d’application met automatiquement à jour toutes les inscriptions d’extensions existantes, supprime les inscriptions obsolètes et inscrit les nouvelles extensions en fonction des déclarations présentes dans les manifestes des anciennes et nouvelles versions de l’application.

Applications utilisées

Le processus de désinscription d’un package d’application du système d’exploitation implique la suppression des éléments internes qui permettent au système d’exploitation de lancer l’application Windows Runtime. Dans certains cas, l’application peut être en cours d’exécution pendant que la mise à jour a lieu. Dans ce scénario, le moteur de déploiement demande la suspension et par la suite l’arrêt de l’application. Le processus de mise à jour réussit ou échoue en fonction du résultat de cette demande. En cas de réussite des opérations, le lancement de l’application n’est pas non plus autorisé pendant la courte période au cours de laquelle ont lieu l’inscription du nouveau package d’application et la désinscription de l’ancien. À la fin de cette étape, le lancement de l’application est à nouveau autorisé.

Données d’application

Les données d’application représentent une entité qui dispose d’une version hors de l’application Windows Runtime réelle. En tant que telle, si l’élément ApplicationData.Version n’a pas été mis à jour lors de la mise à jour de l’application Windows Runtime, l’état de l’application n’est pas affecté par la mise à jour de l’application Windows Runtime.

Retrait de la copie intermédiaire du package

Cette figure illustre l’étape de retrait de la copie intermédiaire du package mis à jour par le système d’exploitation :

Retrait de la copie intermédiaire du package mis à jour de déploiement

Une fois l’opération d’inscription terminée avec succès, si la version préexistante du package n’est pas utilisée par un autre utilisateur sur le système d’exploitation, le package est marqué pour suppression du système d’exploitation. Au départ, le système d’exploitation copie le dossier du package d’application de la version préexistante dans le répertoire %ProgramFiles%\WindowsApps\Deleted. Quand aucune autre opération de déploiement n’est en cours, le système d’exploitation supprime le dossier du package d’application de la version préexistante.

Remarque  Dans des scénarios à plusieurs utilisateurs, le package d’application peut toujours être installé sur le système d’exploitation pour un autre utilisateur. Dans ce cas, la copie intermédiaire du contenu du package n’est pas retirée du système d’exploitation tant que tous les utilisateurs ne l’ont pas supprimée.

Suppression des applications Windows Runtime

Cette figure illustre le déroulement de la suppression des applications Windows Runtime :

Suppression du déploiement

Remarque  De la même façon que les packages sont installés par utilisateur sur un ordinateur, ils ne sont également supprimés que par utilisateur. Si l’application du Windows Store est installée pour plusieurs utilisateurs, elle n’est désinscrite que pour l’utilisateur actuel. Par exemple, si UserA et UserB ont installé l’application Calculatrice et qu’UserA la désinstalle, elle est supprimée uniquement pour UserA et non pour UserB. Le processus de suppression est constitué des mêmes étapes de base que le processus de mise à jour.

Désinscription du package

Cette figure illustre l’étape de désinscription du package supprimé par le système d’exploitation :

Désinscription du package supprimé de déploiement

Avec le processus de désinscription, l’intégration de l’application Windows Runtime au compte de l’utilisateur est supprimée. Toutes les données associées qui ont été installées sur le compte de l’utilisateur, comme l’état de l’application, sont également supprimées. De même que dans le processus de mise à jour, le moteur de déploiement doit demander la suspension et l’arrêt de l’application via le Gestionnaire de durée de vie d’un processus (PLM) afin que l’application puisse être désinscrite du compte de l’utilisateur.

Remarque  Une fois que le PLM retourne un résultat, l’opération de suppression continue de désinscrire l’application Windows Runtime du compte de l’utilisateur. L’opération se poursuit même si le PLM n’a pas abouti.

Retrait de la copie intermédiaire du package

Cette figure illustre l’étape de retrait de la copie intermédiaire du package supprimé par le système d’exploitation :

Retrait de la copie intermédiaire du package supprimé de déploiement

Une fois l’opération de désinscription terminée avec succès, le package, s’il n’est pas utilisé par un autre utilisateur sur le système d’exploitation, est marqué pour suppression du système d’exploitation. Au départ, le système d’exploitation copie le dossier du package d’application du package dans le répertoire %ProgramFiles%\WindowsApps\Deleted. Quand aucune autre opération de déploiement n’est en cours, le système d’exploitation supprime le dossier du package d’application du package.

Remarque  

Dans des scénarios à plusieurs utilisateurs, le package d’application peut toujours être installé sur le système d’exploitation pour un autre utilisateur. Dans ce cas, la copie intermédiaire du contenu du package n’est pas retirée du système d’exploitation tant que tous les utilisateurs ne l’ont pas supprimée.

Déploiement d’une offre groupée d’applications

À partir de Windows 8.1 et de Windows Phone 8.1, vous pouvez déployer des offres groupées d’applications pour optimiser l’empaquetage et la distribution de votre application.

Le déploiement des offres groupées d’applications via le Store utilise ce flux de travail.

Flux de travail de création de packages d’applications

Le processus du déploiement des applications Windows Runtime se déroule en plusieurs étapes. Au départ, le système d’exploitation acquiert et valide le manifeste de l’offre groupée d’applications, le mappage de bloc de l’offre groupée d’applications et la signature de l’offre groupée. Ensuite, le système d’exploitation vérifie le manifeste de l’offre groupée pour s’assurer de la présence d’une application pouvant être déployée dans l’architecture actuelle. Une fois qu’un package d’application approprié est détecté, le système d’exploitation vérifie les critères de déploiement du package d’application pour assurer la réussite du déploiement de l’application.

Le système d’exploitation détermine ensuite le sous-ensemble des packages de ressources applicables pour le déploiement et place ces fichiers binaires de package dans le répertoire \WindowsApps\. Enfin, le système d’exploitation inscrit le package d’application et les packages de ressources dans le compte de l’utilisateur.

Validation

Une fois que l’utilisateur a démarré l’installation d’une application Windows Runtime, le système d’exploitation doit effectuer les vérifications suivantes avant que le déploiement puisse commencer.

TestConditions

Prise en charge de l’architecture

L’offre groupée d’applications peut contenir trois packages d’applications spécifiques à une architecture qui sont spécifiés dans le manifeste de l’offre groupée d’applications.

Version minimale du système d’exploitation

Vous indiquez la configuration requise dans le manifeste du package d’application. Elle indique les éléments requis pour une version du système d’exploitation minimale spécifique. Par exemple, pour Windows 8.1, le numéro de version approprié est 6.3. Pour plus d’informations sur les conditions requises pour l’application, voir Conditions requises pour la création de packages d’application.

Dépendances de l’application

Les applications Windows Runtime peuvent présenter une dépendance d’un autre package de composants pour des fonctionnalités supplémentaires nécessaires à l’application. Pour plus d’informations sur les dépendances des applications, voir Dépendances relatives à la création de packages d’application.

Espace disque

Chaque application Windows Runtime nécessite de l’espace disque pour le déploiement. Si l’espace disque n’est pas suffisant sur l’ordinateur pour déployer le package, le déploiement échoue.

Vérification de la signature

L’intégrité de chaque fichier dans le package d’application doit être vérifiée par rapport au BlockMap validé.

 

Applicabilité des packages

Une fois que le système d’exploitation a déterminé que l’offre groupée d’applications peut être déployée sur le système, il détermine quels packages de ressources déployer avec le package d’application pour améliorer l’expérience de l’utilisateur. L’applicabilité est vérifiée en fonction des trois qualificateurs de ressources spécifiques suivants.

QualificateurDescription

Langue de l’utilisateur

Toute langue que l’utilisateur a ajoutée dans sa liste de langues préférées sera comptabilisée dans l’ensemble final de packages de ressources linguistiques applicables à déployer. Windows 8.1 et versions ultérieures et Windows Phone 8.1 et versions ultérieures prennent en charge un grand nombre de paramètres régionaux et de langues pour les packages de ressources.

Échelle système

Des valeurs d’échelle pour tous les moniteurs seront utilisées pour déterminer l’ensemble final de packages de ressources d’échelle applicables à déployer. Pour Windows 8.1 et versions ultérieures et Windows Phone 8.1 et versions ultérieures, nous recommandons ces facteurs d’échelle pour les packages de ressources :

Windows 8.1 et versions ultérieures:  scale-100, scale-140 et scale-180

Windows Phone 8.1 et versions ultérieures:  scale-100, scale-140 et scale-240

Niveau de fonctionnalité DirectX

Tous les niveaux de fonctionnalité DirectX disponibles dans le système seront utilisés pour déterminer l’ensemble final de packages de ressources DirectX applicables à déployer. Windows 8.1 et versions ultérieures et Windows Phone 8.1 et versions ultérieures prennent en charge trois niveaux de fonctionnalités DirectX pour les packages de ressources : DXFL-DX9, DXFL-DX10 et DXFL-DX11.

 

Copie intermédiaire du package

Une fois que le système d’exploitation a déterminé que l’offre groupée d’applications peut être déployée sur le système et qu’il a identifié les packages à déployer, le contenu du package est téléchargé dans le répertoire \WindowsApps\. Un nouveau répertoire est créé pour chaque package téléchargé et est nommé en utilisant la valeur du nom d’identité du package, comme indiqué ci-dessous.

<Package Name>_<Version>_<Architecture>_<ResourceID>_<Publisher Hash>

Le processus de copie intermédiaire se déroule via un ensemble de demandes effectuées par le moteur de déploiement auprès de la source de l’emplacement du package. Ces demandes sont ensuite satisfaites par la source et retournées au moteur de déploiement où elles sont décompressées, validées par rapport à l’élément BlockMap, puis copiées dans le fichier approprié.

Inscription du package

L’inscription du package représente la dernière étape du processus de déploiement. Au cours de cette phase, deux opérations clés se produisent :

  • Les extensions qui sont déclarées dans le manifeste du package d’application sont inscrites auprès du système d’exploitation. Cela permet à l’application d’être totalement intégrée au système d’exploitation. Par exemple, si vous voulez que votre application soit en mesure d’ouvrir des fichiers .txt, déclarez une extension FileTypeAssociation en tant que données XML dans le manifeste de votre package d’application et indiquez ".txt" comme type de fichier.

    Au moment du déploiement, ces données XML sont converties en un ensemble de modifications système nécessaires pour inscrire correctement l’application afin de gérer des fichiers .txt. Ces modifications sont apportées par le modèle d’application de la part de l’application. Le modèle d’application prend en charge de nombreuses extensions différentes. Pour plus d’informations sur ces extensions, voir Contrats et extensions d’application.

  • Tous les packages de ressources sont inscrits auprès du système de gestion des ressources qui peut ensuite les utiliser pour optimiser l’expérience utilisateur lors de l’exécution de l’application.

Inventaire des packages

Quand des applications Windows Runtime sont installées, mises à jour et supprimées, un utilisateur donné peut à tout moment consulter les packages d’application qui sont installés ou préinstallés.

Remarque  Un utilisateur avec des privilèges d’administrateur peut également identifier les packages d’application qui sont installés pour tous les utilisateurs du système. Pour plus d’informations sur la façon de répertorier les packages sur le système d’exploitation, voir Outils et applets de commande PowerShell.

Forum Aux Questions

Comment puis-je installer plusieurs packages simultanément ?

Vous pouvez installer plusieurs packages en appelant les API de création de packages plusieurs fois ou une seule fois pour tout l’ensemble des packages à installer. L’implémentation sous-jacente du modèle d’application permet à un nombre illimité de packages d’application d’être en attente de déploiement. Toutefois, uniquement 3 opérations de copie intermédiaire simultanées au maximum par utilisateur (un total de 7 opérations de copie intermédiaire simultanées par système d’exploitation) et 1 opération d’inscription par système d’exploitation sont autorisées.

Que se passe-t-il si le package est déjà installé ?

Si le package est déjà installé, un package avec la même identité de package qui est inscrite pour le compte de l’utilisateur actuel existe déjà. Dans ce scénario, le package identique n’est pas installé.

Une mise à jour peut-elle être rendue obligatoire ?

Vous ne pouvez pas rendre une mise à jour obligatoire via le modèle d’application. Le modèle de mise à jour est strictement facultatif. Dans de rares cas, le Store peut juger appropriée la distribution d’une mise à jour en tant que mise à jour prioritaire (par exemple, un correctif de sécurité). Dans ce cas, la mise à jour peut être déployée de force vers les clients.

Remarque  

Dans l’entreprise, vous pouvez être en mesure d’imposer une mise à jour via une stratégie de groupe.

Comment puis-je passer d’une version mise à jour à une version antérieure ?

Vous ne pouvez pas rétablir une version antérieure d’une application Windows Runtime. Dans la mesure où les données du package d’application sont supprimées du système d’exploitation juste après la désinstallation du package, il n’existe aucun moyen de les restaurer.

Puis-je déplacer les répertoires %ProgramFiles%, %ProgramData% ou %UserProfile% ?

Ce scénario n’est pas pris en charge pour les applications Windows Runtime et provoquera des erreurs d’utilisation de l’application.

Interfaces de programmation de création de packages et de déploiement

Windows Runtime

Win32/COM

 

 

Afficher:
© 2015 Microsoft