Solution
Vous construisez déjà le logiciel. En faire un MSIX signé et validé devrait être une étape de votre pipeline, pas un projet à part. La CLI forge_msix d'EtherApps Forge remplace directement makeappx.exe de Microsoft : un dossier de build devient un package signé, validé et testé, sans SDK Windows sur l'agent de build et sans réécrire le script que vous avez déjà.
Sans SDK
la CLI appelle le moteur de packaging de Windows directement sur l'agent de build
Sans licence
les verbes compatibles makeappx ne nécessitent aucune licence
Une étape
créer, signer, valider et tester au sein du pipeline de release
Adéquation au pipeline
Packager une build en MSIX n'est pas une tâche. C'est manifeste, package, signature, validation, test et une voie de mise à jour. Comparé par étape plutôt que par produit :
| Étape du pipeline | Outillage SDK Windows par défaut | forge_msix |
|---|---|---|
| Préparation de l'agent | SDK Windows installé et version figée sur chaque agent | Une copie du dossier CLI dans le PATH. Elle appelle le moteur livré avec Windows |
| Manifeste | Écrit à la main et maintenu à la main au rythme de la build | Généré depuis les ressources de version de l'exécutable, ou versionné dans le dépôt et passé en paramètre |
| Packager et signer | Outils séparés, signature greffée après le packaging | Une seule commande, avec l'identité de l'éditeur alignée sur le sujet du certificat |
| Faire échouer la build | Les codes de sortie ne distinguent pas un package invalide d'une exécution en échec | La validation renvoie un code dédié pour analysé-mais-invalide, la barrière est donc sans ambiguïté |
| Mises à jour sideload | Manifeste app installer écrit et maintenu à la main | Généré depuis l'identité réelle du package signé, compatible bundle |
The problem
Les équipes de développement et les éditeurs de logiciels ne butent pas sur le même problème qu'une équipe de migration. Ici, aucun installeur n'est perdu et il n'y a rien à capturer : la build fonctionne déjà. La friction, c'est tout ce qui vient après. Le packaging MSIX a historiquement signifié une dépendance au SDK Windows sur l'agent de build, une étape de signature greffée après coup, une gestion de certificats dont personne n'est propriétaire, et aucun moyen fiable de faire échouer une build quand le package est mauvais. Résultat : le packaging devient une tâche manuelle effectuée le jour de la livraison, c'est-à-dire exactement là où les erreurs atteignent les clients.
Packager avec l'outil standard suppose d'installer le SDK Windows et d'en figer la version sur chaque agent. C'est une dépendance lourde pour une seule étape, et elle dérive d'un agent à l'autre d'une manière qui n'apparaît que le jour d'une livraison.
Windows n'installera pas un MSIX non signé : signer n'est donc pas optionnel. Le greffer après le packaging revient souvent à laisser un fichier de certificat sur disque avec son mot de passe dans une définition de build, ou à une étape manuelle réalisée par celui qui détient le certificat.
Sans barrière de validation distinguant un package invalide d'une exécution en échec, un package cassé peut traverser le pipeline et atteindre un client, où il échoue à l'installation plutôt qu'à la construction.
Construire un package complet à chaque recompilation pendant le développement est inutile et lent : les équipes cessent donc de tester la forme packagée jusqu'à tard, et le comportement propre au conteneur les surprend à la fin.
What changes
Les verbes de packaging acceptent les mêmes options que makeappx.exe : un script existant continue donc de fonctionner quand on change le binaire. Ces verbes sont sans licence, l'adoption ne commence donc pas par une conversation avec les achats, et le moteur est le composant du système d'exploitation plutôt qu'une réimplémentation.
Générez un manifeste depuis les ressources de version et l'architecture de l'exécutable compilé, ou gardez-en un dans le dépôt pour que identité, éditeur et capacités soient relus comme n'importe quel fichier. Créez et signez ensuite en une commande, depuis un magasin de certificats par empreinte pour qu'aucun mot de passe ne soit écrit dans une définition de build, avec un horodatage RFC 3161 pour que les signatures survivent au certificat.
La validation de schéma s'exécute en préalable, et le verbe de validation renvoie un code de sortie dédié pour un package analysé et jugé invalide, distinct d'une exécution simplement en échec. Sur une release candidate, un test de fumée installe le package signé, le lance et le ferme, le désinstalle et écrit un rapport JSON, et une passe d'évaluation le note face aux bonnes pratiques de packaging.
Pendant le développement, enregistrez la sortie de build comme package non packagé plutôt que de repackager à chaque recompilation, puis validez, lancez et nettoyez en une passe contre une copie de staging isolée. Pour la distribution en sideload, générez un manifeste app installer depuis l'identité réelle du package signé afin que les copies installées se mettent à jour depuis un emplacement HTTPS.
How we deliver it
Cette route est menée par EtherApps Forge, et plus précisément par sa CLI forge_msix. Forge est une application Win32 que vous déployez dans votre propre environnement plutôt qu'un service hébergé : artefacts de build, certificats et packaging restent sous votre contrôle et dans votre pipeline. Si la même organisation possède aussi des logiciels achetés dont les installeurs ont disparu, la route capture-first de la page packaging et déploiement MSIX couvre cette moitié du parc via la même chaîne de signature et de livraison.
EtherApps Forge captures installed Windows applications from running systems, analyses the real application footprint, supports AI-guided packaging decisions, and produces deployment-ready outputs for modern environments.
Where this fits
FAQ
Licences, dépendances de l'agent de build, signature, et en quoi cette route diffère de la route capture-first conçue pour les applications legacy.
Non, et la distinction compte. Le packaging capture-first existe pour les applications dont l'installeur a disparu : l'application en cours d'exécution devient la source de vérité. Cette route suppose l'inverse : vous avez un dossier de build sain et vous voulez qu'il soit packagé, signé et validé comme étape de pipeline. Les deux partagent au bout la même chaîne de signature, de validation et de livraison Intune, ce qui permet aux parcs mêlant logiciels achetés et développés en interne d'utiliser une seule route pour les deux.
Pas pour les verbes compatibles makeappx. Packager, dépackager, bundler, débundler, valider et indexer les ressources sont sans licence : forge_msix fonctionne donc en véritable remplacement direct de makeappx.exe sans rien acheter. Les workflows à valeur ajoutée, c'est-à-dire la création depuis un manifeste, la signature, les tests, l'évaluation, la gestion de certificats et les verbes d'enregistrement pour le développement, nécessitent une licence EtherApps Forge active.
Non. La CLI appelle directement l'API de packaging de Windows, et ce moteur est un composant du système d'exploitation plutôt qu'une dépendance du SDK : les packages obtiennent donc la même validation de schéma, la même block map et la même structure que ceux produits par makeappx. L'agent doit être sous Windows 10 version 1709 ou ultérieure, ou Windows 11, en x64. Le déploiement est un dossier que vous copiez et ajoutez au PATH, sans installeur.
Signez depuis un magasin de certificats par empreinte ou par sujet plutôt que depuis un PFX sur disque, afin qu'aucun mot de passe ne soit écrit dans une définition de build. Ajoutez un serveur d'horodatage RFC 3161 pour que les signatures restent valides après expiration du certificat. Renseignez dans votre manifeste un éditeur strictement identique au sujet du certificat et laissez le mode éditeur en strict, pour qu'un écart arrête la build au lieu de changer discrètement l'identité que vos clients ont déjà installée.
Exécutez le verbe de validation avec sortie JSON et branchez sur le code de sortie. Il distingue un package analysé mais invalide d'un échec opérationnel, ce qui est la différence entre un package cassé et un agent cassé. Gardez hors des pipelines de release les options qui laissent une build passer outre les erreurs de validation ou sémantiques : ce sont des outils de diagnostic pour comprendre pourquoi un package ne se construit pas, pas des réglages à laisser actifs.
Oui. Les applications écrites avant MSIX supposent souvent des comportements que le conteneur n'autorise pas, comme écrire à côté de leur propre exécutable ou attendre un chemin d'installation fixe. Forge met en place le Package Support Framework pour corriger ces cas par redirection des fichiers et du registre et correction du répertoire de travail, sans modifier votre code source. Pour votre propre logiciel, vous préférerez peut-être corriger le comportement à la source, mais le framework évite qu'une livraison soit bloquée entre-temps.
Générez un manifeste app installer depuis le package signé : il dérive l'identité du package lui-même et gère les bundles. Publiez le package et ce manifeste à un emplacement HTTPS, et les copies installées pourront se mettre à jour depuis là. Cela donne aux clients en sideload et aux grands comptes une voie de mise à jour sans référencement en magasin ni réinstallation manuelle.
Oui. Un package peut être extrait dans un répertoire de travail, édité chirurgicalement, validé puis repackagé : valeurs du manifeste, capacités, fichiers de payload et registre virtuel du package sont tous modifiables, et chaque édition du manifeste est validée avant écriture, de sorte qu'une modification malformée est rejetée plutôt qu'enregistrée. Repackager change l'empreinte du contenu : le package doit donc être signé à nouveau ensuite.
Start here
Commencez par l'essai gratuit de 7 jours d'EtherApps Forge et packagez une vraie build de bout en bout, ou parlons du pipeline que vous exploitez déjà et de la place qu'y tiendra l'étape de packaging.
