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à.
Essai gratuit de 7 jours du workflow complet · les licences incluent la formation et le support
Sans carte bancaire. Capturez une vraie application dès le premier jour.
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 |
Le problème
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.
Ce qui change
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.
Forge MSIX CLI pour pipelines de build et usines de packaging MSP : capturez, signez et produisez un MSIX prêt au déploiement depuis une seule commande. Pas de GUI requise.
Forge évalue chaque MSIX par rapport aux signaux de bonnes pratiques depuis la même session CLI : capabilities, alignement de l'éditeur, assets visuels et état de confiance.
Commencer ici
Voyez-le fonctionner sur votre propre tenant.
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à.
Comment nous le réalisons
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.
Capture installed Windows applications, reduce packaging unknowns, and produce modern deployment-ready outputs faster.
Essai gratuit de 7 jours du workflow complet · les licences incluent la formation et le support
Questions
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.
Posez-nous la question lors d'une vérification d'adéquation packagingNon, 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.
Vérifié le 26 août 2026.
Commencer ici
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.
Sans carte bancaire. Capturez une vraie application dès le premier jour.
