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 pour passer à 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 plugins/extensions qui peuvent ne pas avoir 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 intégrées aux 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 bidirectionnelle. 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 des fichiers User.dat et Userclass.dat 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* (comme Registry.dat est utilisé pour HKLM\Software*). Utilisez Userclass.dat si vous avez besoin de clés sous HKCU\Sofware\Classes*.
Voici les méthodes courantes pour 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. Que cliquer avec le bouton droit, exporter et enregistrer en tant que fichier ruche. 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 ether User.dat ou 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 paquets de modification peuvent inclure des configurations nécessaires à définir dans le Registre afin que le package principal s’exécute comme prévu. Cela signifie que votre application principale s’appuie sur le Registre pour voir si un plug-in existe. Lorsque vous déployez le package principal et le package de modification, l’application voit lors de l’exécution le Registre virtuel à la fois du package principal et du package de modification.
Notez que votre package principal peut utiliser le Registre virtuel pour effectuer les opérations suivantes :
- Affichage de l’emplacement où charger le fichier, c’est-à-dire la DLL du plug-in. Si tel 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 lors de l’exécution.
- Affichage de l’emplacement où voir la valeur des clés de Registre virtuel. Votre package principal peut rechercher une valeur qui existe dans le Registre virtuel. Lorsque vous créez votre package de modification, manuellement ou avec notre outil, assurez-vous 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 garantir le fonctionnement des packages de modification dans la version 1903 ou ultérieure, le manifeste du package de modification doit inclure cet élément. Cette opération est effectuée pour vous si vous empaquetez votre package de modification MSIX à l’aide de la version de janvier de l’outil MSIX Packaging Tool. Si vous avez converti un package à l’aide de notre outil avant cette version, vous pouvez modifier votre package existant dans notre outil pour ajouter ce nouvel élément. De plus, si des utilisateurs installent le package de modification, ils sont informés que le package peut modifier l’application principale.
Si vous utilisez un package de modification qui a été créé avant la version 1903, il est nécessaire de modifier le manifeste du package pour mettre à jour l’attribut MaxVersionTested vers 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 MSIX Packaging Tool
Vous pouvez créer un package de modification avec l’outil MSIX Packaging Tool :
Spécifiez le package principal. Veillez à disposer de la version MSIX de votre package principal sur l’ordinateur sur lequel vous effectuez la conversion. Dans le cas contraire, nous vous demanderons de fournir manuellement les informations sur l’éditeur et l’application principale. Par ailleurs, une personnalisation nécessite 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 comporte certaines valeurs dans le Registre virtuel. 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 un package de modification manuellement à l’aide de l’outil MakeAppX.exe qui est inclus dans le kit SDK Windows 10.
Dans le manifeste, spécifiez le package principal. Ajoutez 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 afin de créer les clés de Registre nécessaires pour charger votre package de modification. Cette opération n’est requise que si vous avez besoin que votre application principale voit les clés de Registre personnalisées. N’oubliez pas que, dans la mesure où tout est exécuté à l’intérieur d’un conteneur, le Registre virtuel du package principal et du package de modification fusionnent lors de l’exécution afin que le package principal puisse voir le Registre virtuel des packages de modification.
Ce processus prend également en charge les personnalisations et plug-ins de système de fichiers, tant que l’exécutable de l’application principale ne se trouve pas dans un système de fichiers virtuel. Ceci a pour but de garantir que le package principal obtiendra tous les systèmes de fichiers virtuels 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.