Empaquetez votre app Windows en signed MSIX.

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.

Le certificat de signature ne se trouve pas dans le magasin de confiance que l'appareil vérifie réellement. Importez-le dans le magasin Trusted People de l'ordinateur local, pas dans celui de l'utilisateur actuel ni dans Trusted Root : exportez le certificat du signataire, puis importez-le avec des droits administrateur sous Cert:\LocalMachine\TrustedPeople, ou utilisez « Installer le certificat » en choisissant Ordinateur local plutôt qu'Utilisateur actuel. N'importez jamais un certificat de développement auto-signé dans Trusted Root Certification Authorities ; ce magasin est réservé aux racines des autorités de certification, et y ajouter un certificat non approuvé affaiblit tout le modèle de confiance de l'appareil, pas seulement la confiance envers un paquet.

MSIX Packaging Tool est la voie GUI-first de Microsoft, conçue pour une personne qui suit un assistant pas à pas sur une seule machine. Un pipeline de CI a besoin de l'inverse : aucune interface à cliquer, un code de sortie stable sur lequel se brancher, et des options identiques sur chaque agent de build. forge_msix est CLI-first précisément pour cette raison, de sorte que le packaging devient une étape de pipeline scriptée plutôt qu'une étape manuelle que quelqu'un doit penser à exécuter avant chaque version.