Quel correctif PSF me faut-il ? Un guide par symptôme

Microsoft documente ce qu'est le Package Support Framework. Ce qui est bien plus difficile à trouver, c'est ce dont vous avez réellement besoin à 16 h un jeudi : l'application s'est packagée proprement, elle s'installe, elle se lance, puis elle fait quelque chose de travers. Quel correctif guérit quel symptôme ?

Voici cette correspondance. Elle suppose que le package lui-même est valide et que le problème est comportemental.

Ce que fait réellement PSF

Le Package Support Framework s'intercale entre une application packagée et Windows, et intercepte les appels que l'application émet. MSIX exécute les applications dans un conteneur avec des écritures de fichiers et de registre redirigées, et un répertoire de travail qui n'est pas toujours celui que l'application supposait. Les applications plus anciennes ont été écrites avant que tout cela n'existe, elles demandent donc les choses d'une façon à laquelle le conteneur répond différemment.

Mécaniquement, cela tient en trois pièces. PSFLauncher32.exe ou PSFLauncher64.exe remplace votre application comme attribut Executable de l'élément Application dans le manifeste, afin de s'exécuter en premier. Il lit config.json à la racine du package. Il injecte ensuite le runtime PSF et les DLL de correctif que vous avez nommées dans le processus de l'application, puis l'application démarre derrière eux. Si vous n'êtes pas certain de l'architecture de l'application, le lanceur 32 bits fonctionne dans tous les cas.

PSFLauncher s'exécute en premier, lit la configuration, injecte les correctifs, puis passe la main.

PSF ne corrige pas les bogues. Il traduit des hypothèses.

Cette distinction compte, car elle vous dit quand cesser de recourir à PSF et corriger le package à la place.

Le tableau des symptômes

L'application se lance mais ne trouve immédiatement plus ses propres fichiers. Le répertoire de travail, en général. L'application supposait qu'elle démarrerait dans son dossier d'installation et démarre désormais ailleurs, si bien que les chemins relatifs ne résolvent rien. Lorsqu'aucun répertoire de travail n'est déclaré, Windows utilise System32, ce qui n'est presque jamais ce qu'attendait une application héritée. C'est la cause unique la plus fréquente et la moins coûteuse à corriger, car elle demande une valeur workingDirectory dans config.json et non un correctif de redirection. Vérifiez-la avant toute autre chose.

L'application démarre, fonctionne, et perd ses paramètres d'une session à l'autre. La redirection de fichiers, via FileRedirectionFixup.dll. L'application écrit sa configuration à côté de son exécutable, à l'intérieur du package, là où les écritures ne persistent pas. L'écriture semble réussir et part discrètement nulle part d'utile. Redirigez ces chemins vers un emplacement par utilisateur et les paramètres survivent.

L'application écrit dans son propre dossier d'installation puis échoue au lancement suivant. Même cause racine que ci-dessus, en plus brutal, parce que le fichier qu'elle a écrit est un fichier dont elle a besoin. Même correctif. Dans Process Monitor, cela se lit comme un résultat d'accès refusé sur un chemin situé sous le dossier du package.

Quelque chose échoue uniquement pour les utilisateurs standard et fonctionne pour les administrateurs. Les droits d'accès au registre, le plus souvent, pris en charge par RegLegacyFixups.dll. L'application ouvre une clé au niveau machine et demande plus d'accès qu'il ne lui en faut, typiquement le contrôle total alors qu'elle ne fait que lire. Un administrateur s'en sort, un utilisateur standard non. Le correctif réécrit l'accès demandé en quelque chose que le conteneur accordera, à l'aide de conversions telles que Full2RW et RW2R. Il peut aussi simuler la suppression de clés que l'application tient à retirer, et masquer des clés qui ne devraient pas être visibles dans le conteneur.

Un plug-in, un complément ou un exécutable auxiliaire ne se charge pas. Le chargement dynamique de bibliothèques, via DynamicLibraryFixup.dll. L'application charge quelque chose depuis un chemin que le conteneur résout différemment, ou cherche une dépendance qu'elle s'attend à trouver installée au niveau machine. Sa configuration définit forcePackageDllUse et liste chaque bibliothèque par name avec le filepath relatif au package d'où elle doit provenir. C'est le correctif qui révèle le plus souvent une dépendance non packagée, ce qui est un problème plus vaste qu'un chemin.

Rien d'évident, et aucun schéma clair. Tracez d'abord, avec TraceFixup.dll. Ne devinez pas. Le correctif de traçage enregistre ce que l'application demande réellement, ce qui transforme un jeu de devinettes en une courte liste. Chaque heure passée à tracer en économise plusieurs passées à appliquer des correctifs au hasard en se demandant lequel a aidé.

À quoi ressemble vraiment la configuration

Tout tient dans un seul fichier à la racine du package, et la forme est la même quel que soit le correctif appliqué :

{
  "applications": [
    { "id": "ContosoApp", "executable": "ContosoApp/ContosoApp.exe", "workingDirectory": "ContosoApp/" }
  ],
  "processes": [
    { "executable": "ContosoApp",
      "fixups": [
        { "dll": "FileRedirectionFixup.dll",
          "config": { "redirectedPaths": { "packageRelative": [ { "base": "ContosoApp/", "patterns": [ ".*\\.ini", ".*\\.log" ] } ] } } }
      ] }
  ]
}

Trois choses méritent d'être intégrées. L'id doit correspondre à l'attribut Id de l'élément Application dans le manifeste, sinon rien ne se passe et vous n'obtenez aucune erreur utile. L'executable sous processes est normalement le nom de fichier privé de son chemin et de son extension, et il est traité comme un motif, si bien qu'une valeur négligée attrape plus de processus que prévu. Et applications, processes et fixups sont tous des tableaux, ce qui explique comment un package finit par porter une pile de correctifs que plus personne ne sait expliquer.

Tracez avant de deviner

Deux outils font presque tout le travail de diagnostic, et ils répondent à des questions différentes.

Process Monitor vous dit ce qui s'est passé à la frontière du système d'exploitation. Filtrez sur votre exécutable, excluez les résultats réussis, puis lisez la liste de bas en haut, car les événements les plus récents s'y trouvent. Vous cherchez deux formules : accès refusé, et chemin ou nom introuvable. La première pointe généralement vers la redirection ou les droits d'accès au registre. La seconde pointe vers le répertoire de travail.

Le correctif de traçage raconte la même histoire depuis l'intérieur du processus, et il est conçu pour faire remonter spécifiquement les défauts de compatibilité. Ajoutez la DLL au package et un fragment à config.json :

{ "dll": "TraceFixup.dll", "config": { "traceLevels": { "filesystem": "allFailures" } } }

Par défaut, la trace filtre les échecs qu'elle considère comme attendus, ce qui est généralement souhaitable, car les applications tentent couramment de supprimer des fichiers qui n'ont jamais existé et ignorent le résultat. Le prix à payer, c'est qu'un véritable échec peut se cacher dans le bruit qu'elle retire. Commencez par la valeur par défaut, et n'élargissez à allFailures pour la zone que vous suspectez qu'une fois que la vue par défaut n'a pas expliqué le comportement.

La sortie part vers un débogueur attaché. Si vous ne déboguez pas, lancez DebugView de Sysinternals et lisez-la là. C'est tout le workflow, et il est bien plus rapide que d'appliquer un correctif en espérant.

La règle qui fait gagner le plus de temps

Travaillez dans cet ordre :

1. Reproduisez la panne avec un compte utilisateur standard, pas un compte administrateur. La moitié des rapports « MSIX a tout cassé » sont des hypothèses de permissions qui étaient là depuis toujours et qui étaient jusque-là masquées.
2. Tracez avant de corriger. Découvrez ce que l'application demande.
3. Corrigez le répertoire de travail avant de recourir à la moindre redirection.
4. Appliquez un correctif à la fois et retestez. En empiler trois d'un coup signifie que vous ne saurez jamais lequel était nécessaire, et que vous les traînerez tous les trois pour toujours.

Ce dernier point compte plus qu'il n'y paraît. La configuration des correctifs est quelque chose dont hérite la personne suivante. Un package qui porte trois correctifs alors qu'un seul était nécessaire est un package auquel personne n'osera toucher dans deux ans.

Il existe une cinquième règle qui apparaît après quelques dizaines de packages : écrivez le pourquoi, à côté du package, sous une forme qui survit à la personne qui a décidé. Une ligne par correctif, nommant le symptôme qu'il a guéri, suffit. Sans cela, le relecteur suivant doit reproduire la panne d'origine avant de pouvoir retirer quoi que ce soit sans risque, et c'est pourquoi si peu de correctifs finissent par être retirés.

Quand PSF est la mauvaise réponse

PSF est une cale de compatibilité, et les cales s'accumulent. Tournez-vous vers autre chose quand :

• L'application a besoin d'un pilote ou d'un service au niveau système. Ce n'est pas un problème de conteneur et aucun correctif ne le résoudra. Ce ne devrait probablement pas être du MSIX.
• L'application doit écrire dans un emplacement réellement au niveau machine et d'autres applications doivent le lire. La redirection rend cette écriture invisible pour tous les autres, ce qui ressemble à une correction sans en être une.
• L'application n'échoue que lorsqu'une seconde application est en cours d'exécution. La communication par fichiers partagés, clés de registre partagées ou objets nommés ne survit pas proprement à la conteneurisation, et aucun correctif unique ne la traite.
• Vous en êtes à votre quatrième correctif. À ce stade, la réponse honnête est que cette application n'est pas un bon candidat MSIX aujourd'hui. Un package MSI ou PowerShell App Deployment Toolkit la livrera avec moins de cérémonie, et vous pourrez y revenir plus tard.

Savoir quand s'arrêter fait la différence entre une pratique de packaging et un tas grandissant de cales non documentées. Cela influe aussi sur la livraison : un package qui porte des correctifs se comporte différemment sous App Attach qu'un package propre, c'est le sujet de ce que PSF implique pour App Attach.

Le faire de façon répétée

Diagnostiquer une application de cette façon est satisfaisant. Le faire pour quatre cents relève du problème d'effectifs, et c'est pourquoi la correspondance a tendance à vivre dans la tête d'une seule personne et à partir avec elle.

À l'échelle d'un parc, la correspondance est aussi la mauvaise unité de travail. Ce qu'il vous faut, c'est un verdict par application : livrable telle quelle, livrable avec correctifs, ou pas encore déplaçable. Y arriver vite transforme une conversion d'applications héritées vers MSIX d'un projet sans fin en un calendrier, et c'est le cadrage derrière notre parcours applications héritées.

La place d'EtherApps Forge

EtherApps Forge prépare les correctifs PSF au sein même du packaging plutôt que dans un projet de remédiation distinct mené ensuite, de sorte que la décision est consignée avec le package au lieu d'être mémorisée. L'approche plus large figure sur notre parcours packaging et déploiement MSIX, et la préparation des correctifs elle-même est arrivée dans EtherApps Forge 1.0.6.

L'effet pratique porte sur la répartition des verdicts plutôt que sur un package en particulier. Les applications qui auraient auparavant été mises de côté parce qu'elles se comportaient mal dans le conteneur passent plutôt dans la catégorie « livrable avec correctifs », avec la raison attachée, de sorte que la personne qui ouvrira ensuite le package puisse voir ce qui a été décidé et pourquoi.

EtherApps Forge est une application de bureau Windows assortie d'un essai gratuit de 7 jours, vous pouvez donc éprouver la boucle de diagnostic sur une application que vous savez déjà récalcitrante.

Découvrez le packaging et déploiement MSIX

Commencez par le répertoire de travail, tracez avant de deviner, et ajoutez un correctif à la fois.