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’elle 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 détaillé de chaque composant de Package Support Framework et un guide pas à pas pour l’utiliser.
Comprendre ce qui se trouve à l’intérieur d’une infrastructure de prise en charge de package
L’infrastructure de prise en charge des packages contient un exécutable, une DLL du gestionnaire d’exécution et un ensemble de correctifs d’exécution.
Voici le processus :
- Créez un fichier de configuration qui spécifie les correctifs que vous souhaitez appliquer à votre application.
- 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.
É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 les autorisations de répertoire de travail et de chemin d’accès du programme.
Utilisation du Moniteur de processus pour identifier un problème
Process Monitor est un utilitaire puissant permettant d’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 > ...) pour inclure uniquement les événements de l’exécutable de l’application.
Une liste d’événements s’affiche. Pour la plupart de ces événements, le mot SUCCESS s’affiche dans la colonne Résultat .
Si vous le souhaitez, vous pouvez filtrer les événements pour afficher uniquement les échecs.
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 du fichier de package. Les filtres peuvent également vous aider ici. 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 récemment. Faites particulièrement 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 présente deux problèmes. Vous pouvez voir ces problèmes dans la liste qui apparaît dans l’image suivante.
Dans le premier problème qui apparaît dans cette image, l’application ne parvient pas à lire à partir du fichier « Config.txt » qui se trouve dans le chemin « C:\Windows\SysWOW64 ». Il est peu probable que l’application tente de référencer ce chemin directement. Très probablement, il tente de lire à partir de ce fichier à l’aide d’un chemin 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 sur quelque part dans le package. En regardant à l’intérieur de l’appx, nous pouvons voir que le fichier existe dans le même répertoire que l’exécutable.
Le deuxième problème apparaît dans l’image suivante.
Dans ce problème, l’application ne parvient pas à écrire un fichier .log dans son chemin de package. Cela suggère qu’un correctif de redirection de fichiers peut vous aider.
Étape 2 : Rechercher un correctif d’exécution
Le PSF contient des correctifs d’exécution que vous pouvez utiliser dès maintenant, tels que le correctif de redirection de fichiers.
Correction de la redirection de fichiers
Vous pouvez utiliser le correctif de redirection de fichier 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 à 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é sur notre page GitHub. Il est possible que d’autres développeurs aient résolu un problème similaire au vôtre et aient partagé un correctif du runtime.
Étape 3 : Appliquer un correctif d’exécution
Vous pouvez appliquer un correctif d’exécution existant à l’aide de quelques outils simples à partir 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 de préproduction 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 Windows 10 makeappx.exe de développement logiciel (SDK). C:\Program Files (x86)\Windows Kits\10\bin\x86\makeappx.exe x64 : C:\Program Files (x86)\Windows 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.
Si vous n’avez pas de fichier .msix (ou .appx) pour 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 sélectionnez 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 32 bits et 64 bits nécessaires et les fichiers exécutables au répertoire du package. Inspirez-vous du tableau suivant. Vous souhaiterez également inclure tous 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 d’application est x64 | L’exécutable d’application est x86 |
|---|---|
| PSFLauncher64.exe | PSFLauncher32.exe |
| PSFRuntime64.dll | PSFRuntime32.dll |
| PSFRunDll64.exe | PSFRunDll32.exe |
Le contenu de votre package doit maintenant ressembler à ceci.
Modifier le manifeste du package
Ouvrez le manifeste de votre package dans un éditeur de texte, puis définissez l’attribut Executable de l’élément Application sur le nom du fichier exécutable PSF Launcher. 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-le dans le dossier racine de votre package. Modifiez l’ID d’application déclaré du fichier config.json pour qu’il pointe 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 vers 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 de 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 la 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 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 du correctif, .msix/.appx à charger. |
| correctifs | config | (Facultatif) Contrôle le comportement de la dll de correction. Le format exact de cette valeur varie sur une base de correctif par correctif, car chaque correctif peut interpréter ce « blob » comme il le souhaite. |
Les applicationsclés , processeset fixups 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 d’abord le package.
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érifiez si l’infrastructure de prise en charge des packages est en cours d’exécution
Vous pouvez case activée si votre correctif d’exécution est en cours d’exécution. Pour ce faire, ouvrez le Gestionnaire des tâches et cliquez 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 le correctif de trace
Une autre technique pour diagnostiquer les problèmes de compatibilité des applications empaquetées consiste à utiliser le correctif de trace. Cette DLL est incluse avec le 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 le correctif de trace, ajoutez la DLL au package, ajoutez le fragment suivant à votre fichier config.json, puis empaqueter et installer 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 inconditionnellement 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 toutes les défaillances des fonctions de système de fichiers. Nous le faisons, car nous savons auparavant 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 probablement préférable de commencer à filtrer uniquement en cas d’échecs inattendus, puis à 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 de débogueur et nous allons plutôt utiliser 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 dirigerait vers les mêmes correctifs d’exécution.
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 du runtime
- Ajouter un projet qui démarre l’exécutable du lanceur PSF
- Configurer le projet d’empaquetage
Lorsque vous avez terminé, votre solution ressemblera à ceci.
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 Dynamic-Linked C++ qui contient une ou plusieurs fonctions de remplacement qui servent de correctif au runtime. |
| PSFLauncher | Il s’agit d’un projet vide C++. Ce projet permet de collecter les fichiers distribuables au runtime de l’infrastructure de prise en charge des packages. Il génère un fichier exécutable. Cet 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 consulter 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.
Vous pouvez également ajouter tous les projets d’application dont vous disposez.
Ajouter un projet d’empaquetage
Si vous n’avez pas encore de projet d’empaquetage d’application Windows, créez-en un et ajoutez-le à votre solution.
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 du runtime
Ajoutez un projet de bibliothèque de liens dynamiques (DLL) C++ à la solution.
Cliquez avec le bouton droit sur ce projet, puis choisissez Propriétés.
Dans les pages de propriétés, recherchez le champ Standard du langage C++, puis dans la liste déroulante en regard de ce champ, sélectionnez l’option ISO C++17 Standard (/std:c++17).
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 Tout ou nuget.org.
Cliquez sur l’icône des paramètres en regard de ce champ.
Recherchez le package Nuget PSF*, puis installez-le pour ce projet.
Si vous souhaitez déboguer ou étendre un correctif d’exécution existant, ajoutez les fichiers de correctif d’exécution que vous avez obtenus à l’aide des instructions décrites dans la section Rechercher un correctif d’exécution de ce guide.
Si vous envisagez de créer un correctif, n’ajoutez rien à ce projet pour le moment. 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 Projet vide C++ à la solution.
Ajoutez le package Nuget PSF à ce projet en suivant les mêmes instructions que celles 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 en fonction de l’architecture de votre application.
Ajoutez une référence de projet au projet de correctif d’exécution dans votre solution.
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 le local | 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épendances de 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.
Choisissez le projet lanceur PSF et votre projet d’application de bureau, puis cliquez sur le bouton OK .
Notes
Si vous n’avez pas le code source de votre application, il vous suffit de choisir 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.
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 du package sur Contenu.
{
"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 la 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 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 de la DLL de correction à charger. |
| correctifs | config | (Facultatif) Contrôle le comportement de la DLL de correction. Le format exact de cette valeur varie sur une base de correctif par correctif, 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 applicationsclés , processeset fixups 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 démarre est l’application lanceur PSF, qui à son tour démarre votre application de bureau cible. Pour déboguer l’application de bureau cible, vous devez l’attacher manuellement au 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 de runtime natif, sélectionnez les types de code managé et natif (débogage en mode mixte).
Une fois que vous avez configuré ce paramètre, 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 de votre application, vous pouvez définir des points d’arrêt uniquement en regard des lignes de code dans votre projet de correctif d’exécution.
É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 des erreurs de refus 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 libres 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 pour 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ée 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. En effet, la plupart des techniques JIT impliquent le lancement du 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 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 WinDbg débogage enfant et définissez les points d’arrêt appropriés.
.childdbg 1
g
(Exécutez jusqu’au démarrage de l’application cible et jusqu’à ce que l’application cible s’arrête dans le débogueur)
sxe ld fixup.dll
g
(exécuter jusqu’à ce que la DLL de correction soit chargée)
bp ...
Notes
PLMDebug peut également être utilisé pour attacher un débogueur à une application au lancement. Il est également inclus dans les outils de débogage pour Windows. Toutefois, il est plus complexe à utiliser que la prise en charge directe désormais fournie par WinDbg.
Assistance technique
Des questions ? Demandez-nous sur l’espace de conversation Package Support Framework sur le site de la communauté technique MSIX.