Solution
Conçu pour les développeurs et ISV qui compilent déjà une application de bureau qui fonctionne. Concentrez-vous sur votre produit, pas sur la plomberie de l’installateur. La CLI forge_msix d’EtherApps Forge transforme un dossier de build en MSIX signé et validé comme étape de pipeline, sans Windows SDK sur l’agent et sans réécrire le script que vous exécutez 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
Comment ça marche
Vous avez déjà les binaires. Voici les étapes qui transforment ce build en un package signé que vos clients peuvent installer.
Copiez le dossier de la CLI dans le PATH. Pas d’installation du Windows SDK, pas de figement de versions d’outils SDK entre agents. La CLI appelle le moteur de packaging livré avec Windows.
Partez du dossier que votre CI produit déjà : exécutables, dépendances et tout fichier appartenant au package. Il n’y a rien à capturer. Le build est la source de vérité.
Exécutez forge_msix prepare sur l’exécutable compilé pour générer un manifeste à partir de ses ressources de version et de son architecture, ou conservez un manifeste relu dans le contrôle de code et passez-le.
Exécutez forge_msix create sur le dossier de build avec signature depuis le magasin de certificats par empreinte, plus un horodatage RFC 3161. L’identité publisher est alignée sur le sujet du certificat pour une identité de package stable.
Exécutez forge_msix validate et faites échouer le build si le package est invalide. Livrez l’artefact pour téléchargement direct, déploiement Microsoft Intune ou Configuration Manager, ou générez un flux de mise à jour app installer pour les clients en sideload.
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 développeurs et ISV ne sont pas bloqués sur le même problème qu’une équipe de migration. Il n’y a pas d’installateur perdu ni rien à capturer : le build fonctionne déjà. La friction, c’est tout ce qui suit. Le packaging MSIX a signifié une dépendance Windows SDK sur l’agent, une étape de signature ajoutée après coup, une gestion de certificats sans propriétaire clair, et aucun moyen fiable de faire échouer un build quand le package est incorrect. Le packaging devient un travail manuel au moment du release, exactement là où les erreurs atteignent les clients.
Les éditeurs indépendants et les équipes produit passent trop de temps sur les particularités du packaging Windows au lieu de livrer des fonctionnalités. MSIX doit être une étape de release, pas un projet parallèle.
Packager avec l’outil standard signifie installer et figer la version du Windows SDK sur chaque agent. C’est une dépendance lourde pour une seule étape, et elle dérive entre agents d’une façon qui n’apparaît souvent que le jour du release.
Les clients qui déploient avec Intune ou Configuration Manager ont souvent besoin d’un MSIX signé avant d’acheter. Si le packaging est lent ou manuel, cela devient un blocage commercial autant que technique.
Sans une porte de validation qui distingue un package invalide d’une exécution en échec, un package cassé peut traverser la pipeline et atteindre un client, où il échoue à l’installation plutôt qu’au build.
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.
Le pipeline de la build au MSIX
forge_msix génère un manifeste depuis l'exécutable compilé, package et signe en une commande, valide le résultat avec un code de sortie qui fait échouer la build, et produit un MSIX signé. Une courte dérivation publie un flux de mise à jour app installer pour les clients en sideload. Chaque étape s'exécute dans le pipeline de release que vous avez déjà.
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 d’agent de build, signature, intégration CI, et la différence avec la route capture-first pour les applications héritées.
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.
Placez forge_msix dans le PATH de l’agent, pointez vers votre dossier de build publié, exécutez forge_msix prepare pour générer un manifeste à partir de l’exécutable compilé, puis forge_msix create avec signature depuis le magasin de certificats par empreinte. Contrôlez la release avec forge_msix validate et, éventuellement, générez un flux app installer pour les mises à jour sideload. Les mêmes commutateurs qu’utilise déjà un script makeappx continuent de fonctionner.
Oui. forge_msix est une CLI conçue pour des agents non interactifs. Exécutez-la depuis Azure DevOps, GitHub Actions, GitLab CI, Jenkins ou tout agent de build Windows scripté. Packaging, signature et validation deviennent des étapes de la même définition de release que vos autres artefacts.
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 avec l’essai gratuit de 7 jours d’EtherApps Forge et packagez de bout en bout un vrai build développeur ou ISV, ou parlez-nous de la pipeline que vous exécutez déjà et de l’endroit où l’étape de packaging doit s’insérer.
