Prise en main de Package Support Framework

Package Support Framework est un kit de open source qui vous permet d’appliquer des correctifs à votre application de bureau existante (sans modifier le code) afin qu’il puisse s’exécuter dans un conteneur MSIX. Le Framework de prise en charge de package aide votre application à respecter les bonnes pratiques de l’environnement d’exécution moderne.

Cet article fournit un aperçu indépide de chaque composant de Package Support Framework et du guide pas à pas pour l’utiliser.

Comprendre ce qui se trouve à l’intérieur d’un Framework de support de package

Package Support Framework contient un exécutable, une DLL du gestionnaire d’exécution et un ensemble de correctifs d’exécution.

Framework de prise en charge de package

Voici le processus :

  1. Créez un fichier de configuration qui spécifie les correctifs que vous souhaitez appliquer à votre application.
  2. Modifiez votre package pour qu’il pointe vers le fichier exécutable du lanceur PSF (Package Support Framework).

Lorsque les utilisateurs démarrent votre application, le lanceur Package Support Framework est le premier exécutable qui s’exécute. Il lit votre fichier de configuration et injecte les correctifs de runtime et la DLL de gestionnaire de runtime dans le processus d’application. Le gestionnaire de runtime applique le correctif quand l’application en a besoin pour s’exécuter à l’intérieur d’un conteneur MSIX.

Injection de DLL de l’infrastructure de prise en charge des packages

Étape 1 : Identifier les problèmes de compatibilité des applications empaquetées

Tout d’abord, créez un package pour votre application. Ensuite, installez-le, exécutez-le et observez son comportement. Vous recevrez peut-être des messages d’erreur qui vous aideront à identifier un problème de compatibilité. Vous pouvez également utiliser Process Monitor pour identifier les problèmes. Les problèmes courants concernent les hypothèses d’application concernant le répertoire de travail et les autorisations de chemin d’accès au programme.

Utilisation de Process Monitor pour identifier un problème

Process Monitor est un utilitaire puissant pour observer les opérations de fichier et de registre d’une application, ainsi que leurs résultats. Cela peut vous aider à comprendre les problèmes de compatibilité des applications. Après avoir ouvert Process Monitor, ajoutez un filtre (filtre > de filtre...) pour inclure uniquement les événements de l’exécutable de l’application.

Filtre d’application ProcMon

Une liste d’événements s’affiche. Pour la plupart de ces événements, le mot SUCCESS apparaît dans la colonne Result .

Événements ProcMon

Si vous le souhaitez, vous pouvez filtrer les événements pour afficher uniquement les échecs.

ProcMon Exclude Success

Si vous soupçonnez un échec d’accès au système de fichiers, recherchez les événements ayant échoué qui se trouvent sous System32/SysWOW64 ou le chemin d’accès au fichier de package. Les filtres peuvent également vous aider ici aussi. Commencez en bas de cette liste et faites défiler vers le haut. Les échecs qui apparaissent en bas de cette liste se sont produits plus récemment. Faites attention aux erreurs qui contiennent des chaînes telles que « accès refusé » et « chemin/nom introuvable », et ignorez les éléments qui ne semblent pas suspects. Le PSFSample a deux problèmes. Vous pouvez voir ces problèmes dans la liste qui s’affichent dans l’image suivante.

ProcMon Config.txt

Dans le premier problème qui apparaît dans cette image, l’application ne parvient pas à lire le fichier « Config.txt » qui se trouve dans le chemin d’accès « C:\Windows\SysWOW64 ». Il est peu probable que l’application tente de référencer ce chemin directement. Il est très probable qu’il tente de lire à partir de ce fichier à l’aide d’un chemin d’accès relatif, et par défaut, « System32/SysWOW64 » est le répertoire de travail de l’application. Cela suggère que l’application s’attend à ce que son répertoire de travail actuel soit défini quelque part dans le package. À l’intérieur de l’appx, nous pouvons voir que le fichier existe dans le même répertoire que l’exécutable.

Config.txtd’application

Le deuxième problème s’affiche dans l’image suivante.

ProcMon Logfile

Dans ce problème, l’application ne parvient pas à écrire un fichier .log dans son chemin d’accès au package. Cela suggère qu’un correctif de redirection de fichiers peut vous aider.

Étape 2 : Rechercher un correctif d’exécution

PsF contient des correctifs d’exécution que vous pouvez utiliser pour le moment, tels que le correctif de redirection de fichiers.

Correctif de redirection de fichiers

Vous pouvez utiliser le correctif de redirection de fichiers pour rediriger les tentatives d’écriture ou de lecture de données dans un répertoire qui n’est pas accessible à partir d’une application qui s’exécute dans un conteneur MSIX.

Par exemple, si votre application écrit dans un fichier journal qui se trouve dans le même répertoire que l’exécutable de vos applications, vous pouvez utiliser le correctif de redirection de fichiers pour créer ce fichier journal dans un autre emplacement, tel que le magasin de données d’application local.

Correctifs d’exécution de la communauté

Veillez à consulter les contributions de la communauté à notre page GitHub . Il est possible que d’autres développeurs aient résolu un problème similaire à votre vôtre et qu’ils aient partagé un correctif d’exécution.

Étape 3 : Appliquer un correctif d’exécution

Vous pouvez appliquer un correctif d’exécution existant avec quelques outils simples du Kit de développement logiciel (SDK) Windows, et en suivant ces étapes.

  • Créer un dossier de disposition de package
  • Obtenir les fichiers Package Support Framework
  • Ajoutez-les à votre package
  • Modifier le manifeste du package
  • Créer un fichier de configuration

Passons en revue chaque tâche.

Créer le dossier de disposition du package

Si vous avez déjà un fichier .msix (ou .appx), vous pouvez décompresser son contenu dans un dossier de disposition qui servira de zone intermédiaire pour votre package. Vous pouvez le faire à partir d’une invite de commandes à l’aide de l’outil MakeAppx, en fonction de votre chemin d’installation du Kit de développement logiciel (SDK), c’est là que vous trouverez l’outil makeappx.exe sur votre pc Windows 10 : x86 : C:\Program Files : x86 : Windows Kits\10\bin\x86\makeappx.exe Kits\10\bin\x64\makeappx.exe

makeappx unpack /p PSFSamplePackage_1.0.60.0_AnyCPU_Debug.msix /d PackageContents

Cela vous donnera quelque chose qui ressemble à ce qui suit.

Disposition du package

Si vous n’avez pas de fichier .msix (ou .appx) à commencer, vous pouvez créer le dossier de package et les fichiers à partir de zéro.

Obtenir les fichiers Package Support Framework

Vous pouvez obtenir le package Nuget PSF à l’aide de l’outil en ligne de commande Nuget autonome ou via Visual Studio.

Obtenir le package à l’aide de l’outil en ligne de commande

Installez l’outil en ligne de commande NuGet à partir de cet emplacement : https://www.nuget.org/downloads. Ensuite, à partir de la ligne de commande Nuget, exécutez cette commande :

nuget install Microsoft.PackageSupportFramework

Vous pouvez également renommer l’extension de package pour .zip et la décompresser. Tous les fichiers dont vous avez besoin se trouvent sous le dossier /bin.

Obtenir le package à l’aide de Visual Studio

Dans Visual Studio, cliquez avec le bouton droit sur votre nœud de solution ou de projet et choisissez l’une des commandes Gérer les packages NuGet. Recherchez Microsoft.PackageSupportFramework ou PSF pour rechercher le package sur Nuget.org. Ensuite, installez-le.

Ajouter les fichiers Package Support Framework à votre package

Ajoutez les DLL PSF et les fichiers exécutables 32 bits et 64 bits requis au répertoire du package. Inspirez-vous du tableau suivant. Vous souhaiterez également inclure les correctifs d’exécution dont vous avez besoin. Dans notre exemple, nous avons besoin du correctif du runtime de redirection de fichiers.

L’exécutable de l’application est x64 L’exécutable de l’application est x86
PSFLauncher64.exe PSFLauncher32.exe
PSFRuntime64.dll PSFRuntime32.dll
PSFRunDll64.exe PSFRunDll32.exe

Votre contenu de package doit maintenant ressembler à ceci.

Fichiers binaires de package

Modifier le manifeste du package

Ouvrez votre manifeste de package dans un éditeur de texte, puis définissez l’attribut Executable de l’élément Application sur le nom du fichier exécutable du lanceur PSF. Si vous connaissez l’architecture de votre application cible, sélectionnez la version appropriée, PSFLauncher32.exe ou PSFLauncher64.exe. Si ce n’est pas le cas, PSFLauncher32.exe fonctionnera dans tous les cas. Voici un exemple.

<Package ...>
  ...
  <Applications>
    <Application Id="PSFSample"
                 Executable="PSFLauncher32.exe"
                 EntryPoint="Windows.FullTrustApplication">
      ...
    </Application>
  </Applications>
</Package>

Créer un fichier de configuration

Créez un nom config.jsonde fichier et enregistrez ce fichier dans le dossier racine de votre package. Modifiez l’ID d’application déclaré du fichier config.json pour pointer vers l’exécutable que vous venez de remplacer. À l’aide des connaissances que vous avez acquises à l’aide de Process Monitor, vous pouvez également définir le répertoire de travail et utiliser le correctif de redirection de fichiers pour rediriger les lectures/écritures dans les fichiers .log sous le répertoire « PSFSampleApp » relatif au package.

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

Voici un guide pour le schéma config.json :

Array key Valeur
applications id Utilisez la valeur de l’attribut Id de l’élément Application dans le manifeste du package.
applications executable Chemin d’accès relatif au package vers l’exécutable que vous souhaitez démarrer. Dans la plupart des cas, vous pouvez obtenir cette valeur à partir de votre fichier manifeste de package avant de le modifier. Il s’agit de la valeur de l’attribut Executable de l’élément Application .
applications workingDirectory (Facultatif) Chemin d’accès relatif au package à utiliser comme répertoire de travail de l’application qui démarre. Si vous ne définissez pas cette valeur, le système d’exploitation utilise le System32 répertoire comme répertoire de travail de l’application.
processus executable Dans la plupart des cas, il s’agit du nom du executable fichier configuré ci-dessus avec le chemin d’accès et l’extension de fichier supprimés.
correctifs dll Chemin d’accès relatif au package vers le correctif, .msix/.appx à charger.
correctifs config (Facultatif) Contrôle le comportement de la dll fixup. Le format exact de cette valeur varie selon un correctif par correction, car chaque correctif peut interpréter ce « blob » comme il le souhaite.

Les applicationstableaux , processeset fixups les clés sont des tableaux. Cela signifie que vous pouvez utiliser le fichier config.json pour spécifier plusieurs DLL d’application, de processus et de correction.

Empaqueter et tester l’application

Ensuite, créez un package.

makeappx pack /d PackageContents /p PSFSamplePackageFixup.msix

Ensuite, signez-le.

signtool sign /a /v /fd sha256 /f ExportedSigningCertificate.pfx PSFSamplePackageFixup.msix

Pour plus d’informations, consultez comment créer un certificat de signature de package et comment signer un package à l’aide de signtool

À l’aide de PowerShell, installez le package.

Notes

N’oubliez pas de désinstaller le package en premier.

powershell Add-AppPackage .\PSFSamplePackageFixup.msix

Exécutez l’application et observez le comportement avec le correctif d’exécution appliqué. Répétez les étapes de diagnostic et d’empaquetage si nécessaire.

Vérifier si l’infrastructure de prise en charge du package est en cours d’exécution

Vous pouvez vérifier si votre correctif d’exécution est en cours d’exécution. Pour ce faire, vous pouvez ouvrir le Gestionnaire des tâches et cliquer sur Plus de détails. Recherchez l’application à laquelle l’infrastructure de prise en charge du package a été appliquée et développez les détails de l’application pour obtenir plus de détails. Vous devez être en mesure de voir que l’infrastructure de prise en charge du package est en cours d’exécution.

Utiliser la correction de trace

Une autre technique pour diagnostiquer les problèmes de compatibilité d’application empaqueté consiste à utiliser le correctif de trace. Cette DLL est incluse dans la fonction PSF et fournit une vue de diagnostic détaillée du comportement de l’application, similaire à Process Monitor. Il est spécialement conçu pour révéler les problèmes de compatibilité des applications. Pour utiliser trace Fixup, ajoutez la DLL au package, ajoutez le fragment suivant à votre fichier config.json, puis empaquetez et installez votre application.

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

Par défaut, le correctif de trace filtre les échecs qui peuvent être considérés comme « attendus ». Par exemple, les applications peuvent essayer de supprimer sans condition un fichier sans vérifier s’il existe déjà, en ignorant le résultat. Cela a la conséquence malheureuse que certains échecs inattendus peuvent être filtrés. Par conséquent, dans l’exemple ci-dessus, nous choisissons de recevoir tous les échecs des fonctions de système de fichiers. Pour ce faire, nous savons que la tentative de lecture à partir du fichier Config.txt échoue avec le message « fichier introuvable ». Il s’agit d’un échec qui est fréquemment observé et qui n’est généralement pas supposé être inattendu. Dans la pratique, il est préférable de commencer à filtrer uniquement en cas d’échecs inattendus, puis de revenir à tous les échecs s’il existe un problème qui ne peut toujours pas être identifié.

Par défaut, la sortie du correctif de trace est envoyée au débogueur attaché. Pour cet exemple, nous n’allons pas attacher un débogueur et utiliserons plutôt le programme DebugView de SysInternals pour afficher sa sortie. Après avoir exécuté l’application, nous pouvons voir les mêmes échecs qu’auparavant, ce qui nous redirigerait vers les mêmes correctifs d’exécution.

Fichier TraceShim introuvable

Accès traceShim refusé

Déboguer, étendre ou créer un correctif d’exécution

Vous pouvez utiliser Visual Studio pour déboguer un correctif d’exécution, étendre un correctif d’exécution ou en créer un à partir de zéro. Vous devrez faire ces choses pour réussir.

  • Ajouter un projet d’empaquetage
  • Ajouter un projet pour le correctif d’exécution
  • Ajouter un projet qui démarre l’exécutable du lanceur PSF
  • Configurer le projet d’empaquetage

Lorsque vous avez terminé, votre solution ressemble à ceci.

Solution terminée

Examinons chaque projet dans cet exemple.

Project Objectif
DesktopApplicationPackage Ce projet est basé sur le projet d’empaquetage d’applications Windows et génère le package MSIX.
Runtimefix Il s’agit d’un projet de bibliothèque C++ Dynamic-Linked qui contient une ou plusieurs fonctions de remplacement qui servent de correctif d’exécution.
PSFLauncher Il s’agit du projet vide C++. Ce projet est un emplacement pour collecter les fichiers distribuables au moment de l’exécution de l’infrastructure de prise en charge du package. Il génère un fichier exécutable. Ce fichier exécutable est la première chose qui s’exécute lorsque vous démarrez la solution.
WinFormsDesktopApplication Ce projet contient le code source d’une application de bureau.

Pour examiner un exemple complet qui contient tous ces types de projets, consultez PSFSample.

Passons en revue les étapes de création et de configuration de chacun de ces projets dans votre solution.

Créer une solution de package

Si vous n’avez pas encore de solution pour votre application de bureau, créez une solution vide dans Visual Studio.

Solution vide

Vous pouvez également ajouter les projets d’application dont vous disposez.

Ajouter un projet d’empaquetage

Si vous n’avez pas encore de projet d’empaquetage d’applications Windows, créez-en un et ajoutez-le à votre solution.

Modèle de projet de package

Pour plus d’informations sur le projet d’empaquetage d’applications Windows, consultez Empaqueter votre application à l’aide de Visual Studio.

Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet d’empaquetage, sélectionnez Modifier, puis ajoutez-le au bas du fichier projet :

<Target Name="PSFRemoveSourceProject" AfterTargets="ExpandProjectReferences" BeforeTargets="_ConvertItems">
<ItemGroup>
  <FilteredNonWapProjProjectOutput Include="@(_FilteredNonWapProjProjectOutput)">
  <SourceProject Condition="'%(_FilteredNonWapProjProjectOutput.SourceProject)'=='<your runtime fix project name goes here>'" />
  </FilteredNonWapProjProjectOutput>
  <_FilteredNonWapProjProjectOutput Remove="@(_FilteredNonWapProjProjectOutput)" />
  <_FilteredNonWapProjProjectOutput Include="@(FilteredNonWapProjProjectOutput)" />
</ItemGroup>
</Target>

Ajouter un projet pour le correctif d’exécution

Ajoutez un projet DLL (Dynamic-Link Library) C++ à la solution.

Bibliothèque de correctifs runtime

Cliquez avec le bouton droit sur ce projet, puis choisissez Propriétés.

Dans les pages de propriétés, recherchez le champ C++ Language Standard, puis, dans la liste déroulante en regard de ce champ, sélectionnez l’option ISO C++17 Standard (/std:c++17).

ISO 17 Option

Cliquez avec le bouton droit sur ce projet, puis dans le menu contextuel, choisissez l’option Gérer les packages Nuget . Vérifiez que l’option source du package est définie sur All ou nuget.org.

Cliquez sur l’icône paramètres en regard de ce champ.

Recherchez le package Nuget PSF*, puis installez-le pour ce projet.

package nuget

Si vous souhaitez déboguer ou étendre un correctif d’exécution existant, ajoutez les fichiers de correctif du runtime que vous avez obtenus à l’aide des instructions décrites dans la section Rechercher un correctif d’exécution de ce guide.

Si vous avez l’intention de créer un correctif, n’ajoutez rien à ce projet. Nous vous aiderons à ajouter les fichiers appropriés à ce projet plus loin dans ce guide. Pour l’instant, nous allons continuer à configurer votre solution.

Ajouter un projet qui démarre l’exécutable du lanceur PSF

Ajoutez un projet de projet vide C++ à la solution.

Projet vide

Ajoutez le package Nuget PSF à ce projet à l’aide des mêmes instructions décrites dans la section précédente.

Ouvrez les pages de propriétés du projet et, dans la page Paramètres généraux, définissez la propriété PSFLauncher32Nom cible sur ou PSFLauncher64 selon l’architecture de votre application.

Référence du lanceur PSF

Ajoutez une référence de projet au projet de correctif runtime dans votre solution.

Informations de référence sur les correctifs runtime

Cliquez avec le bouton droit sur la référence, puis dans la fenêtre Propriétés , appliquez ces valeurs.

Propriété Valeur
Copier localement True
Copier les assemblys satellites locaux True
Sortie de l’assembly de référence True
Lier les dépendances de la bibliothèque False
Entrées de dépendance de la bibliothèque de liens False

Configurer le projet d’empaquetage

Dans le projet d’empaquetage, cliquez avec le bouton droit sur le dossier Applications , puis choisissez Ajouter une référence.

Ajouter une référence de projet

Choisissez le projet Lanceur PSF et votre projet d’application de bureau, puis choisissez le bouton OK .

Projet de bureau

Notes

Si vous n’avez pas le code source dans votre application, choisissez simplement le projet Lanceur PSF. Nous allons vous montrer comment référencer votre exécutable lorsque vous créez un fichier de configuration.

Dans le nœud Applications , cliquez avec le bouton droit sur l’application Lanceur PSF, puis choisissez Définir comme point d’entrée.

Définir le point d’entrée

Ajoutez un fichier nommé config.json à votre projet d’empaquetage, puis copiez et collez le texte json suivant dans le fichier. Définissez la propriété Action de package sur Content.

{
    "applications": [
        {
            "id": "",
            "executable": "",
            "workingDirectory": ""
        }
    ],
    "processes": [
        {
            "executable": "",
            "fixups": [
                {
                    "dll": "",
                    "config": {
                    }
                }
            ]
        }
    ]
}

Fournissez une valeur pour chaque clé. Utilisez ce tableau comme guide.

Array key Valeur
applications id Utilisez la valeur de l’attribut Id de l’élément Application dans le manifeste du package.
applications executable Chemin d’accès relatif au package vers l’exécutable que vous souhaitez démarrer. Dans la plupart des cas, vous pouvez obtenir cette valeur à partir de votre fichier manifeste de package avant de le modifier. Il s’agit de la valeur de l’attribut Executable de l’élément Application .
applications workingDirectory (Facultatif) Chemin d’accès relatif au package à utiliser comme répertoire de travail de l’application qui démarre. Si vous ne définissez pas cette valeur, le système d’exploitation utilise le System32 répertoire comme répertoire de travail de l’application.
processus executable Dans la plupart des cas, il s’agit du nom du executable fichier configuré ci-dessus avec le chemin d’accès et l’extension de fichier supprimés.
correctifs dll Chemin relatif au package vers la DLL de correction à charger.
correctifs config (Facultatif) Contrôle le comportement de la DLL de correction. Le format exact de cette valeur varie selon un correctif par correction, car chaque correctif peut interpréter ce « blob » comme il le souhaite.

Lorsque vous avez terminé, votre config.json fichier ressemblera à ceci.

{
  "applications": [
    {
      "id": "DesktopApplication",
      "executable": "DesktopApplication/WinFormsDesktopApplication.exe",
      "workingDirectory": "WinFormsDesktopApplication"
    }
  ],
  "processes": [
    {
      "executable": ".*App.*",
      "fixups": [ { "dll": "RuntimeFix.dll" } ]
    }
  ]
}

Notes

Les applicationstableaux , et fixupsprocessesles clés sont des tableaux. Cela signifie que vous pouvez utiliser le fichier config.json pour spécifier plusieurs dll d’application, de processus et de correction.

Déboguer un correctif d’exécution

Dans Visual Studio, appuyez sur F5 pour démarrer le débogueur. La première chose qui commence est l’application lanceur PSF, qui démarre à son tour votre application de bureau cible. Pour déboguer l’application de bureau cible, vous devez attacher manuellement le processus d’application de bureau en choisissant Déboguer-Attacher> au processus, puis en sélectionnant le processus d’application. Pour autoriser le débogage d’une application .NET avec une DLL de correctif d’exécution native, sélectionnez des types de code managés et natifs (débogage en mode mixte).

Une fois que vous avez configuré cela, vous pouvez définir des points d’arrêt en regard des lignes de code dans le code de l’application de bureau et le projet de correctif du runtime. Si vous n’avez pas le code source dans votre application, vous pouvez définir des points d’arrêt uniquement en regard des lignes de code dans votre projet de correctif runtime.

Étant donné que le débogage F5 exécute l’application en déployant des fichiers libres à partir du chemin du dossier de disposition du package, plutôt que d’installer à partir d’un package .msix/.appx, le dossier de disposition n’a généralement pas les mêmes restrictions de sécurité qu’un dossier de package installé. Par conséquent, il peut ne pas être possible de reproduire les erreurs de déni d’accès au chemin d’accès au package avant d’appliquer un correctif d’exécution.

Pour résoudre ce problème, utilisez le déploiement de package .msix / .appx plutôt que le déploiement de fichiers libre F5. Pour créer un fichier de package .msix / .appx, utilisez l’utilitaire MakeAppx à partir du Kit de développement logiciel (SDK) Windows, comme décrit ci-dessus. Ou, à partir de Visual Studio, cliquez avec le bouton droit sur le nœud de votre projet d’application, puis sélectionnez Store -> Créer des packages d’application.

Un autre problème avec Visual Studio est qu’il n’a pas de prise en charge intégrée de l’attachement à des processus enfants lancés par le débogueur. Cela rend difficile le débogage de la logique dans le chemin de démarrage de l’application cible, qui doit être attaché manuellement par Visual Studio après le lancement.

Pour résoudre ce problème, utilisez un débogueur qui prend en charge l’attachement de processus enfant. Notez qu’il n’est généralement pas possible d’attacher un débogueur juste-à-temps (JIT) à l’application cible. Cela est dû au fait que la plupart des techniques JIT impliquent de lancer le débogueur à la place de l’application cible, via la clé de Registre ImageFileExecutionOptions. Cela élimine le mécanisme de déviation utilisé par PSFLauncher.exe pour injecter des FixupRuntime.dll dans l’application cible. WinDbg, inclus dans les outils de débogage pour Windows et obtenu à partir du Kit de développement logiciel (SDK) Windows, prend en charge l’attachement de processus enfant. Il prend également en charge le lancement et le débogage directs d’une application UWP.

Pour déboguer le démarrage de l’application cible en tant que processus enfant, démarrez WinDbg.

windbg.exe -plmPackage PSFSampleWithFixup_1.0.59.0_x86__7s220nvg1hg3m -plmApp PSFSample

À l’invite, activez le débogage enfant et définissez les points d’arrêt WinDbg appropriés.

.childdbg 1
g

(exécutez jusqu’à ce que l’application cible démarre et se sépare du débogueur)

sxe ld fixup.dll
g

(exécutez jusqu’à ce que la DLL de correction soit chargée)

bp ...

Notes

PLMDebug peut également être utilisé pour attacher un débogueur à une application lors du lancement, et est également inclus dans les outils de débogage pour Windows. Toutefois, il est plus complexe d’utiliser que la prise en charge directe désormais fournie par WinDbg.

Support

Des questions ? Demandez-nous sur l’espace de conversation Package Support Framework sur le site de la communauté technique MSIX.