Convertir EXE en APPX

Un outil de déploiement d’entreprise, un workflow Microsoft Store ou un environnement Windows plus ancien peut nécessiter un package .appx au lieu d’un programme d’installation fourni par le fournisseur. L’application installée doit être empaquetée, recevoir une identité et un manifeste, puis être signée ; renommer Setup.exe en .appx ne la convertit pas.

Formats EXE et APPX

EXE est l’extension de nom de fichier courante des exécutables Windows, généralement pour un programme Portable Executable (PE). Les éditeurs de logiciels utilisent des fichiers EXE pour les applications, les outils en ligne de commande, les programmes de désinstallation et les programmes d’installation créés avec des systèmes tels que Inno Setup, NSIS, InstallShield, WiX Burn et Visual Studio.

Un programme d’installation EXE peut copier des fichiers, créer des entrées de registre, installer des prérequis, enregistrer des composants COM, créer des services ou télécharger du contenu supplémentaire. Ces actions ne fournissent pas le manifeste du package, l’identité de l’application, les ressources, les déclarations de dépendances, la block map et la signature requises par un package APPX.

APPX est un format de package d’application Windows signé, basé sur ZIP, introduit avec Windows 8. Il contient AppxManifest.xml, les fichiers de l’application, les ressources visuelles, les déclarations de dépendances si nécessaire, AppxBlockMap.xml et une signature de package.

APPX fournit un emplacement d’installation défini, une identité d’application, une vérification de l’intégrité, un comportement de désinstallation plus propre et un déploiement versionné. Il peut être déployé par l’intermédiaire de systèmes de gestion d’entreprise, de PowerShell et de workflows Store compatibles. .msix est son successeur plus récent et constitue généralement le meilleur format de sortie pour les déploiements Windows actuels ; créez un APPX uniquement lorsque la plateforme destinataire l’exige explicitement.

Empaquetage d’une application de bureau

Utilisez le programme d’installation d’origine et n’empaquetez que les logiciels que vous possédez ou que vous êtes autorisé à redistribuer. Vérifiez d’abord que la destination nécessite réellement .appx ; de nombreux systèmes de déploiement actuels acceptent MSIX et ne tirent aucun avantage d’un package APPX plus ancien.

1. Créez une machine virtuelle propre correspondant à la version et à l’architecture Windows cibles. Supprimez les copies précédentes de l’application et évitez d’installer des logiciels sans rapport pendant la capture.
2. Installez le MSIX Packaging Tool de Microsoft depuis Microsoft Store ou depuis sa source de publication Microsoft officielle. Il s’agit de l’outil de capture privilégié pour les applications Win32 existantes, bien que sa sortie normale soit au format MSIX.
3. Démarrez une capture locale de package d’application, sélectionnez l’EXE du programme d’installation et fournissez ses paramètres silencieux documentés s’ils sont disponibles, tels que /S, /quiet ou /VERYSILENT. Les switches du programme d’installation sont propres à chaque produit.
4. Installez et configurez l’application pendant la capture. Ne capturez pas les mises à jour Windows, les pilotes, les extensions de navigateur, les prérequis sans rapport ou les données propres à l’utilisateur.
5. Fournissez l’identité du package, la version, l’architecture, les informations d’affichage et les ressources visuelles. L’éditeur du manifeste doit correspondre exactement au sujet du certificat de signature, par exemple CN=Contoso Software.
6. Testez le package obtenu sur une autre machine cible propre. Testez le lancement, la mise à jour, les associations de fichiers, les gestionnaires de protocoles, l’impression, les licences et chaque intégration requise.

Pour obtenir obligatoirement une sortie APPX, créez une disposition de package compatible avec APPX contenant le manifeste, les fichiers binaires, les ressources et les dépendances, puis utilisez l’outil MakeAppx.exe du Windows SDK :

MakeAppx.exe pack /d C:\AppxLayout /p C:\Packages\Contoso.App.appx /o

La disposition capturée pour un package MSIX peut nécessiter des modifications du manifeste ou de la compatibilité avant de pouvoir être générée au format APPX. Ne vous contentez pas de remplacer l’extension .msix générée par .appx.

Signez le package final avec un certificat de signature de package d’application approuvé par les appareils cibles :

SignTool.exe sign /fd SHA256 /f C:\Certificates\Contoso.pfx /p <password> C:\Packages\Contoso.App.appx

Validez la signature avec SignTool.exe verify /pa /v C:\Packages\Contoso.App.appx. Pour les tests internes, distribuez et approuvez le certificat de test par l’intermédiaire du processus de gestion des certificats de l’organisation. La soumission à Store nécessite l’identité du package et l’éditeur attribués par l’intermédiaire de Partner Center ; un certificat auto-signé arbitraire ne convient pas à la distribution via Store.

Limites de compatibilité

Empaquetez l’application installée plutôt que de placer son programme d’installation dans un package. Un APPX qui lance Setup.exe reste un programme d’installation et échoue généralement aux exigences de déploiement d’entreprise ou de Store.

L’empaquetage ne rend pas toutes les dépendances Win32 compatibles. Les pilotes du noyau, les composants au démarrage, les logiciels de sécurité de bas niveau, les programmes d’installation à l’échelle de la machine, les applications nécessitant une élévation à chaque lancement et les applications qui modifient des emplacements système protégés nécessitent souvent une stratégie de déploiement distincte ou des modifications du code. Certains services, scénarios COM, extensions du shell et comportements liés au système de fichiers ou au registre disposent d’une prise en charge de l’empaquetage spécifique à la version de Windows et doivent être testés sur la version cible prise en charge la plus ancienne.

Générez et testez des packages x86, x64 et arm64 distincts lorsque cela est applicable. Une mise à jour doit conserver la même identité de package et le même éditeur ; un package signé par un éditeur différent ne peut pas mettre à jour le package installé.

Le Package Support Framework peut résoudre certains problèmes courants des applications de bureau, tels que les hypothèses concernant le répertoire de travail et certains comportements liés au registre ou aux chemins de fichiers, mais il ne peut pas empaqueter les pilotes ni supprimer les exigences d’élévation. Évitez les convertisseurs « EXE to APPX » accessibles depuis un navigateur : une conversion légitime doit exécuter le programme d’installation, inspecter ses modifications, créer un manifeste et protéger les identifiants de signature ; aucun service en ligne réputé ne peut donc produire en toute sécurité un package testé à partir d’un logiciel arbitraire.