Personnaliser vos applications d’entreprise avec des packages de modification

La possibilité de personnaliser l’expérience d’une application est importante, en particulier pour les entreprises. Nous avons parlé aux professionnels de l’informatique et nous savons que la personnalisation des applications pour répondre aux besoins de leur utilisateur est essentielle à l’effort de déplacement vers Windows 10. Lors de la personnalisation des applications empaquetées à l’aide de MSI, il est bien compris que les professionnels de l’informatique doivent acquérir le package auprès des développeurs et re-empaqueter le programme d’installation avec la personnalisation en fonction de leurs besoins. Il s’agit d’un effort coûteux pour les entreprises. À l’avenir, nous voulons dissocier la personnalisation et l’application principale afin que le re-empaquetage ne soit plus nécessaire. Cela garantit que les entreprises obtiennent les dernières mises à jour des développeurs tout en conservant le contrôle de leurs personnalisations.

Dans Windows 10, version 1809, nous avons introduit un nouveau type de package MSIX appelé package de modification. Les packages de modification sont des packages MSIX qui stockent les personnalisations. Les packages de modification peuvent également être des plug-ins/modules complémentaires qui n’ont peut-être pas de point d’activation. Les professionnels de l’informatique peuvent utiliser cette fonctionnalité pour modifier de manière flexible les conteneurs MSIX afin que les applications soient superposées par les personnalisations de leur entreprise.

Fonctionnement

Les packages de modification sont conçus pour les entreprises qui ne possèdent pas le code de l’application et qui ont uniquement le programme d’installation. Vous pouvez créer un package de modification à l’aide de la dernière version de l’outil d’empaquetage MSIX (pour Windows 10 version 1809 ou ultérieure). Si vous avez le code de l’application, vous pouvez également créer une extension d’application.

Si vous souhaitez créer un package de modification qui a une liaison stricte à l’application principale, vous pouvez déclarer l’application principale comme dépendance dans le manifeste du package de modification.

<Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.15063.0"/>
    <uap4:MainPackageDependency Name="Main.App"/>
</Dependencies>

L’exemple suivant montre comment spécifier un autre certificat ou éditeur.

<Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.15063.0"/>
    <uap4:MainPackageDependency Name="Main.App" Publisher="CN=Contoso, C=US" />
</Dependencies>

Il s’agit d’une configuration simple si la relation entre le package de modification et le package principal est un-à-un. Les personnalisations classiques nécessitent souvent des clés de Registre sous HKEY_CURRENT_USER ou HKEY_CURRENT_USERCLASS. Dans notre package MSIX, nous avons User.dat et Userclass.dat fichiers pour capturer les clés de Registre. Vous devez créer User.dat si vous avez besoin de clés de Registre sous HKCU\Software* (tout comme Registry.dat est utilisé pour HKLM\Software*). Utilisez Userclass.dat si vous avez besoin de clés sous HKCU\Sofware\Classes*.

Voici les façons courantes de créer un fichier .dat :

• Utilisez Regedit pour créer un fichier. Créez une ruche dans Regedit et insérez les clés nécessaires. Au lieu de cliquer avec le bouton droit, exporter et enregistrer en tant que fichier Hive. Veillez à nommer le fichier User.dat ou Userclass.dat

• Utilisez une API pour créer des fichiers nécessaires. Vous pouvez utiliser la fonction ORSaveHive pour enregistrer un fichier .dat. Veillez à nommer le fichier soit User.dat soit Userclass.dat.

Une fois que vous avez apporté les modifications nécessaires, vous pouvez créer le package de modification comme n’importe quel autre package MSIX. Vous pouvez ensuite déployer le package avec la configuration de déploiement actuelle. Lorsque vous relancez votre application principale, vous pouvez voir les modifications apportées au package de modification. Si vous choisissez de supprimer le package de modification, votre application principale revient à un état sans le package de modification.

Découvrez les packages de modification installés sur votre appareil

À l’aide de PowerShell, vous pouvez voir les packages de modification installés à l’aide de la commande suivante.

Get-AppPackage -PackageTypeFilter Optional

Packages de modification sur Windows 10, version 1809

Sur Windows 10, version 1809, les packages de modification peuvent inclure des configurations nécessaires pour être définis dans le Registre, de sorte que le package principal s’exécute comme prévu. Cela signifie que votre application principale tire parti du Registre pour voir si un plug-in existe. Lorsque vous déployez le package principal et le package de modification, au moment de l’exécution, l’application affiche le registre virtuel (VREG) du package principal et du package de modification.

Notez que votre package principal peut utiliser le VREG pour effectuer les opérations suivantes :

• Affichage de l’emplacement de chargement du fichier (DLL) du plug-in. Si c’est le cas, vérifiez que le fichier fait partie du package. En procédant ainsi, le package principal est en mesure d’accéder au fichier au moment de l’exécution.
• Affichage de l’emplacement où voir la valeur des clés de Registre virtuel. Votre package principal peut être à la recherche d’une valeur qui existe dans le VREG. Lorsque vous créez votre package de modification manuellement ou à l’aide de notre outil, vérifiez que la valeur est correcte.

Packages de modification sur Windows 10, version 1903 et ultérieures

Les fonctionnalités suivantes ont été ajoutées à Windows 10 version 1903.

Mise à jour du manifeste

Nous avons ajouté la prise en charge de l’élément suivant au manifeste du package de modification MSIX.

<Properties>
   <rescap6:ModificationPackage>true</rescap6:ModificationPackage>
</Properties>

Pour vous assurer que les packages de modification fonctionnent dans la version 1903 ou ultérieure, le manifeste du package de modification doit inclure cet élément. Cette opération sera effectuée pour vous si vous empaquetez votre package de modification MSIX à l’aide de la version de janvier de l’outil d’empaquetage MSIX. Si vous avez converti un package à l’aide de notre outil avant la publication, vous pouvez modifier votre package existant dans notre outil pour ajouter ce nouvel élément. En outre, si les utilisateurs installent le package de modification, ils sont avertis que le package peut modifier l’application principale.

Si vous utilisez un package de modification créé avant la version 1903, il est nécessaire de modifier le manifeste du package pour mettre à jour l’attribut MaxVersionTested sur 10.0.18362.0.

<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17701.0" MaxVersionTested="10.0.18362.0" />

Créer un package de modification à l’aide de l’outil d’empaquetage MSIX

Vous pouvez créer un package de modification avec MSIX Packaging Tool :

• Spécifiez le package principal. Veillez à disposer de la version MSIX de votre package principal disponible sur votre ordinateur sur lequel vous effectuez la conversion. Si ce n’est pas le cas, nous vous demanderons de fournir manuellement les informations de l’éditeur et de l’application principale. En outre, certaines personnalisations nécessitent que votre application principale soit installée sur votre ordinateur.

• Modifiez le package une fois qu’il a été converti à l’aide de l’éditeur de package. Il peut arriver que le package principal exige que votre package de modification ait certaines valeurs dans leur VREG. C’est là où vous allez modifier le package de façon appropriée.

Créer un package de modification à l’aide de MakeAppx.exe

Vous pouvez créer manuellement un package de modification à l’aide de l’outil MakeAppX.exe inclus dans le Kit de développement logiciel (SDK) Windows 10.

• Dans le manifeste, spécifiez le package principal. Incluez l’éditeur et le nom du package principal.

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17701.0" MaxVersionTested="12.0.0.0"/>
    <uap4:MainPackageDependency Name="HeadTrax" Publisher="CN=Contoso Software, O=Contoso Corporation, C=US" />
  </Dependencies>
  

• Créez Registry.dat, User.dat et Userclass.dat pour créer les clés de Registre nécessaires pour charger votre package de modification. Cela n’est nécessaire que si vous avez besoin de votre application principale pour afficher les clés de Registre personnalisées. N’oubliez pas que, étant donné que tout s’exécute à l’intérieur d’un conteneur, au moment de l’exécution, le package principal et le registre virtuel du package de modification fusionne de sorte que le package principal puisse afficher le registre virtuel des packages de modification.

Ce processus prend également en charge les plug-ins et les personnalisations du système de fichiers, tant que l’exécutable de l’application principale n’est pas dans un système de fichiers virtuel (VFS). Cela permet de s’assurer que le package principal obtient tous les fichiers VFS du package principal et du package de modification.

Installer des packages de modification sur l’ordinateur

L’installation de packages de modification sur l’ordinateur suit d’autres conventions d’installation. Il est important de noter que vous souhaiterez peut-être utiliser le paramètre -OptionalPackagePath lors de l’installation du package.

Résolution de conflits

Si plusieurs packages de modification tentent de modifier la même valeur, le conflit est résolu en tenant compte de l’ordre alphabétique des noms des packages de modification.