EtherApps Forge 1.0.6 : correctifs PSF et packaging MSIX pour les développeurs

EtherApps Forge 1.0.6 est disponible et élargit le produit dans deux directions à la fois. Les applications legacy qui se packagent proprement mais se comportent ensuite mal dans le conteneur MSIX peuvent désormais être corrigées par des correctifs Package Support Framework mis en place dans le cadre du packaging. Et pour la première fois, Forge ne sert plus uniquement aux applications que vous capturez dans le parc de quelqu'un d'autre : la CLI forge_msix remplace directement makeappx.exe de Microsoft, si bien qu'une équipe de développement ou un éditeur de logiciels peut transformer son propre dossier de build en MSIX signé et validé au sein d'un pipeline existant.

Les deux évolutions répondent à la même plainte, depuis les extrémités opposées du problème de packaging. Construire un package n'est plus la partie difficile depuis un moment. Le faire fonctionner correctement, et à chaque livraison de build, c'est là que se trouve le vrai travail.

Correctifs de compatibilité PSF : quand l'application se package bien mais ne se comporte pas

Le résultat le plus frustrant dans un programme MSIX n'est pas un package qui échoue à la construction. C'est un package qui se construit, se signe, s'installe, se lance, puis fait discrètement la mauvaise chose.

Cela arrive parce que le conteneur MSIX change les règles pour lesquelles une application ancienne a été écrite. Trois schémas en causent l'essentiel :

• Écrire à côté de son propre exécutable. Les applications qui déposent réglages, journaux ou fichiers de licence dans leur propre dossier d'installation écrivent à un emplacement que le conteneur protège.
• Supposer un chemin d'installation fixe. Tout ce qui contient un chemin C:\Program Files\Vendor\App codé en dur, ou un lanceur qui attend un répertoire de travail précis, ne trouve ni l'un ni l'autre là où il l'attend.
• Lire des emplacements de registre machine. La configuration conservée sous HKLM que le conteneur redirige n'est plus là où l'application la cherche.

Le Package Support Framework est la réponse open source de Microsoft à exactement cela. Il applique des correctifs ciblés à l'exécution, sans aucune modification du code source de l'application, et les plus importants sont la redirection des fichiers et du registre ainsi que la correction du répertoire de travail. Quand une application legacy n'a plus d'éditeur pour la reconstruire, le PSF fait souvent la différence entre une application qui part en production et une qui est abandonnée.

Depuis la 1.0.6, Forge met en place le framework dans le cadre du packaging plutôt que de le laisser en étape manuelle a posteriori. L'effet pratique sur une évaluation est que la catégorie d'applications marquées "déployable avec correctifs" s'élargit nettement, et que la catégorie "ne peut pas encore migrer" se réduit. Nous avons expliqué pourquoi cette couche de remédiation compte pour app attach et la livraison MSIX dans le Package Support Framework et le risque MSIX app attach, et cela s'applique tout aussi directement aux packages livrés par Intune sur des postes physiques.

Packaging développeur et ISV : vos propres builds, signées et validées

Le packaging capture-first résout un problème legacy : l'installeur a disparu, donc l'application en cours d'exécution devient la source de vérité. Cela n'a jamais représenté tout le marché. Beaucoup d'équipes disposent d'un dossier de build parfaitement sain et trouvent malgré tout MSIX pénible, parce que l'outillage autour suppose un SDK Windows installé, une étape de signature greffée après coup et une personne pour vérifier le résultat.

forge_msix est conçu comme un remplacement direct de makeappx.exe. Il appelle le moteur de packaging de Windows directement au lieu de dépendre d'un SDK installé sur l'agent de build, et les verbes de packaging acceptent les mêmes options, si bien qu'un script existant continue de fonctionner quand vous changez le binaire.

Au-delà de la parité, la version ajoute les éléments dont un pipeline de release a réellement besoin :

# Scaffold a manifest from the built executable
forge_msix prepare .\publish\MyApp.exe
# Create and sign in one step, from the agent certificate store
forge_msix create -s .\publish --package-output .\artifacts\MyApp.msix `
  --sign --cert-sha1 $env:SIGNING_THUMBPRINT --cert-store My --cert-machine-store `
  --timestamp-server http://timestamp.digicert.com --validate-schema
# Gate the build on structural validation
forge_msix validate /p .\artifacts\MyApp.msix --json

Trois détails comptent pour câbler cela dans la CI. Signez depuis un magasin de certificats par empreinte plutôt qu'avec un PFX sur disque, afin qu'aucun mot de passe ne finisse dans une définition de build. Ajoutez un horodatage RFC 3161 pour que les signatures restent valides après l'expiration du certificat. Et branchez sur le code de sortie, car validate distingue "le package a été analysé et est invalide" de "l'exécution elle-même a échoué", ce qui est la différence entre un build cassé et un agent cassé.

Il existe aussi un verbe de test de fumée qui installe le package signé, le lance et le ferme, le désinstalle et écrit un rapport JSON, ainsi qu'une passe d'évaluation qui note un package face à des signaux de bonnes pratiques de packaging. Aucun des deux n'a sa place à chaque commit. Les deux méritent d'être exécutés sur une release candidate.

Pour les équipes qui livrent hors magasin, make-appinstaller génère le manifeste .appinstaller à partir de l'identité réelle du package signé, afin que les copies installées en sideload puissent se mettre à jour depuis un emplacement HTTPS.

Ce que cela change si votre parc est mixte

La plupart des organisations ne sont pas purement l'un ou l'autre. Elles ont des logiciels achetés dont les installeurs ont disparu, une poignée d'applications métier développées en interne, et une échéance Windows 11 ou Intune qui couvre l'ensemble. Jusqu'ici, ces deux moitiés empruntaient des routes et des outils différents.

Avec la 1.0.6, elles partagent une route de packaging : capture-first pour les applications dont l'installeur a disparu, packaging depuis le dossier de build pour celles que vos propres développeurs compilent, remédiation PSF pour tout ce que le conteneur contrarie, et la même signature, validation et livraison Intune au bout. La décision de route reste celle d'un humain. La mécanique cesse d'être deux projets distincts.

Disponibilité

EtherApps Forge 1.0.6.0 est disponible dès maintenant. Forge est une application Win32 que vous déployez dans votre propre environnement plutôt qu'un service hébergé, si bien que les captures et le packaging restent sous votre contrôle, et il capture aussi bien depuis d'anciennes versions de Windows que depuis les versions actuelles. Chaque licence inclut la formation et le support, et un essai gratuit de 7 jours permet à une équipe de packaging, d'endpoint ou de développement de prouver le résultat sur une application réelle avant d'engager le reste du parc.

Si votre blocage est une application legacy que personne ne peut reconstruire, commencez par moderniser les applications Windows legacy ou par notre guide sur le repackaging d'une application quand l'installeur est perdu. Si le blocage est côté livraison, packaging et déploiement MSIX couvre la signature, la revue PSF et le déploiement Intune. Le produit lui-même se trouve sur EtherApps Forge.

Essayez EtherApps Forge gratuitement pendant 7 jours et packagez une application réelle, capturée ou compilée, de la source au MSIX signé.