Mises à jour de package d’application

  • Article

La mise à jour des packages d’applications Windows modernes est optimisée pour garantir que seuls les bits modifiés essentiels de l’application sont téléchargés pour mettre à jour une application Windows existante.

Métadonnées dans le fichier AppxBlockMap.xml

De manière générale, lors de la création de package, un élément de métadonnées est créé et stocké dans le fichier de package d’application (.appx ou .msix), ce qui permet à des composants du package d’être identifiés de manière unique par Windows. Lors de la mise à jour d’un package d’application, Windows utilise le fichier de métadonnées pour comparer l’ancien package au nouveau et déterminer ce qui doit être téléchargé sur l’appareil.

Comme les métadonnées permettent à des composants du package d’être identifiés de manière unique, cela signifie que le mécanisme de mise à jour différentielle fonctionne parfaitement à partir de n’importe quelle version d’un package vers une autre version d’un package (en supposant que le package source comporte une version inférieure au package cible).

Les métadonnées sont contenues dans le fichier AppxBlockMap.xml (les métadonnées mentionnées ci-dessus). Le fichier AppxBlockMap.xml est un fichier XML qui contient une liste à deux dimensions des informations sur les fichiers dans le package. La première dimension présente des détails d’ordre général sur le fichier (par exemple, nom et taille) et la deuxième dimension fournit des représentations du hachage SHA2-256 de chaque secteur de 64 Ko de ce fichier (le « bloc »).

Voici un exemple d’un fichier AppxBlockMap.xml.

<!--?xml version="1.0" encoding="UTF-8"?-->
<blockmap hashmethod="http://www.w3.org/2001/04/xmlenc#sha256" 
          xmlns="http://schemas.microsoft.com/appx/2010/blockmap">
  <file lfhsize="66" size="101188" name="asset1.jpg">
    <block hash="2bidNE0JyaO+FjaTpRe0g8HzUCblUf/cfBcTXiZR74c="/>
    <block hash="+jeFwKrGk5gw9wSICWsWRtEQXwcLC7af4EWS7DgrAkY="/>
  </file>
  <file lfhsize="61" size="108823" name="asset2.jpg">
    <block hash="u0+5S0GOzwyAfYx54tKycZyHRBYm2ybvq27dkIKqDsQ="/>
    <block hash="F9h0FRMetL6BNCszAYB0bgyx2KWN+dO1bls4Q9m267c="/>
  </file>
  ...
</blockmap>

Le premier fichier (asset1.jpg) comporte deux hachages de blocs. Le premier hachage représente le premier bloc de 64 Ko du fichier et le deuxième hachage, les 35 Ko restants (sur la base d’un fichier de 101 188 octets).

Pendant une mise à jour, si le deuxième bloc de ce fichier est modifié, le hachage est également mis à jour pour intégrer cette modification. Le composant de téléchargement extrait le deuxième bloc et réutilise le premier bloc inchangé de l’ancien package.

Sur une plus grande échelle, si un fichier entier ne change pas (déterminé par un ensemble complet de blocs sans modification), ce fichier peut être réutilisé à partir du package existant, ce qui permet de gagner du temps et des ressources.

Contraintes de mise à jour d’application

Les mises à jour sont effectuées au sein de la même famille de packages

Le nom de la famille de packages se compose du nom de package et de l’éditeur. Pour être en mesure d’effectuer la mise à jour, les nouvelles métadonnées de package doivent être identiques à celles du package déjà installé. Voici un exemple de nom de famille de packages : Contoso.ContosoApp_8wekyb3d8bbwe.

Les mises à jour d’application doivent incrémenter à une version supérieure

En général, les mises à jour d’application nécessitent que la version du nouveau package soit supérieure à la version du package actuel. Le processus de mise à jour d’application n’autorise pas l’installation par défaut des packages avec des versions inférieures. Depuis Windows 10 version 1809, vous pouvez utiliser ForceUpdateToAnyVersion pour autoriser l’installation de packages de version inférieure quand un commutateur de remplacement est fourni dans le cadre des arguments de mise à jour. Il est actuellement disponible dans PowerShell en utilisant l’option ForceUpdateFromAnyVersion via PackageManager API, EnterpriseModernAppManagement CSP et dans le fichier AppInstaller.

Remarque

Si vous utilisez ForceUpdateToAnyVersion sur une application du Windows Store, Windows Update le met automatiquement à jour avec la dernière version applicable.

Le package de mise à jour d’application peut avoir une architecture différente

Le package de mise à jour du package d’application actuellement installé peut avoir une architecture différente, tant que la nouvelle architecture est prise en charge sur le système d’exploitation sur lequel elle est déployée. Par exemple : si vous avez installé la version x86 de MyFavApp(v1.0.0.0) sur un appareil Windows 10 x64 et que le package de mise à jour (v2.0.0.0) est une version x64 : MyFavApp(1.0.0.0) sera mis à jour avec succès sur MyFavApp(v2.0.0.0).

Les packages peuvent être mis à jour de MSIX vers MSIXbundle

Un package de mise à jour peut passer de MSIX à MSIXbundle, mais pas l’inverse. Lorsqu’un package MSIXbundle est installé, la mise à jour de package doit rester un bundle.

Optimiser la technologie de mise à jour différentielle

Il existe quelques façons de vérifier que la technologie de mise à jour différentielle est optimisée au maximum.

  • Conserver des fichiers de petite taille dans le package : cela permet de garantir que, si une modification nécessaire a un impact sur le fichier entier, la mise à jour est néanmoins minime.
  • Les modifications apportées aux fichiers doivent être additives si possible : des modifications additives garantissent que les appareils des utilisateurs finaux téléchargent uniquement les blocs modifiés.
  • Les modifications apportées aux fichiers doivent être limitées à des blocs de 64 Ko si possible : si votre application contient des fichiers volumineux et nécessite des changements au milieu d’un fichier, la limitation des modifications à un ensemble de blocs est particulièrement utile.