Mises à jour de package d’applicationApp package updates

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.Updating modern Windows app packages is optimized to ensure that only the essential changed bits of the app are downloaded to update an existing Windows app.

Métadonnées dans le fichier AppxBlockMap.xmlMetadata in the AppxBlockMap.xml file

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.At a high level, during package creation, a piece of metadata is created and stored in the app package file (.appx or .msix) which allows parts of the package to be uniquely identified by 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.When updating an app package, Windows uses the metadata file to compare the old package to the new package and determine what needs to be downloaded to the device.

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).Since the metadata allows parts of the package to be uniquely identified, this means the differential update machinery fully functions from any version of a package to any other version of a package (assuming the source package has a lower version than the target package).

Les métadonnées sont contenues dans le fichier AppxBlockMap.xml (les métadonnées mentionnées ci-dessus).The metadata is contained in the AppxBlockMap.xml file (the aforementioned metadata). Le fichier AppxBlockMap.xml est un fichier XML qui contient une liste à deux dimensions des informations sur les fichiers dans le package.The AppxBlockMap.xml file is an XML file that contains a two dimensional list of information about files in the 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 »).The first dimension lays out high level details on the file (e.g., name and size) and the second dimension provides SHA2-256 hash representations of each 64KB slice of that file (the "block").

Voici un exemple d’un fichier AppxBlockMap.xml.Here's a sample of an AppxBlockMap.xml file.

<!--?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).The first hash represents the first 64KB block of the file and the second hash represents the remaining 35KB - given the file is 101188 bytes.

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.During an update, if the second block of that file is modified, the hash is also updated to reflect that. Le composant de téléchargement extrait le deuxième bloc et réutilise le premier bloc inchangé de l’ancien package.The download component pulls down the second block and reuses the first unchanged block from the old 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.On a larger scale, if an entire file does not change (determined by a full set of blocks not changing), that file can be reused from the existing package, saving time and resources.

Contraintes de mise à jour d’applicationApp update constraints

Les mises à jour sont effectuées au sein de la même famille de packagesUpdates are performed within the same package family

La famille de packages se compose du nom de package et de l’éditeur.The package family is comprised of the Package Name and Publisher. 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é.To be able to update, the new package metadata will need to be the same as the previously installed package.

Les mises à jour d’application doivent incrémenter à une version supérieureApp updates must increment to a higher version

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.In general, app updates require the version of the new package to be higher than the current one. Le processus de mise à jour d’application n’autorise pas l’installation par défaut des packages avec des versions inférieures.The app update process will not allow packages with lower versions to be installed by default. 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.Starting in Windows 10 version 1809, you can use ForceUpdateToAnyVersion to allow lower version packages to be installed when an override switch is provided as part of the update arguments. Il est actuellement disponible dans PowerShell en utilisant l’option ForceUpdateFromAnyVersion via PackageManager API, EnterpriseModernAppManagement CSP et dans le fichier AppInstaller.It is currently available in PowerShell using the ForceUpdateFromAnyVersion option, via PackageManager API, EnterpriseModernAppManagement CSP and in the AppInstaller file.

Notes

Si vous utilisez ForceUpdateToAnyVersion sur une application du Windows Store, Windows Update le met automatiquement à jour avec la dernière version applicable.If you use ForceUpdateToAnyVersion on an app from the Windows Store, Windows Update will automatically update the to the latest applicable version.

Le package de mise à jour d’application peut avoir une architecture différenteApp update package can have a different architecture

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.The update package to the currently installed app package can be of a different architecture as long as the new architecture is supported on the OS where it is being deployed to. Par exemple : Si la version x86 de MyFavApp(v1.0.0.0) est installée sur un appareil Windows 10 x64 et que le package de mise à jour (v2.0.0.0) affiche la version x64 : MyFavApp(1.0.0.0) est correctement mis à jour vers MyFavApp(v2.0.0.0).For example: If you have x86 version of MyFavApp(v1.0.0.0) installed on a x64 Windows 10 device and the update package(v2.0.0.0) is x64 version: MyFavApp(1.0.0.0) will be updated to MyFavApp(v2.0.0.0) successfully.

Les packages peuvent être mis à jour de MSIX vers MSIXbundlePackages can update from an MSIX to an MSIXbundle

Un package de mise à jour peut passer de MSIX à MSIXbundle, mais pas l’inverse.An update package can go from MSIX package to an MSIXbundle package but not vice-versa. Lorsqu’un package MSIXbundle est installé, la mise à jour de package doit rester un bundle.When an MSIXbundle is installed, the package update will need to remain a bundle.

Optimiser la technologie de mise à jour différentielleOptimize differential update technology

Il existe quelques façons de vérifier que la technologie de mise à jour différentielle est optimisée au maximum.There are a few ways to ensure that the differential update technology is optimized to the max.

  • 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.Keep files in the package small - doing this will ensure that if a change is needed that would impact the full file, the update would still be small.
  • 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.Changes to files should be additive if possible - additive changes will ensure that end-user devices only download those changed blocks.
  • 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.Changes to files should be contained to 64KB blocks if possible - if your app does have large files and requires changes to the middle of a file, containing changes to a set of blocks will help significantly.