Prise en main de Package Support Framework
Package Support Framework est un kit code source ouvert qui vous aide à 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épible de chaque composant de l’infrastructure de prise en charge de package et un guide pas à pas pour l’utiliser.
Comprendre ce qui se trouve à l’intérieur d’un framework de support de package
Le Framework de prise en charge de package contient un exécutable, une DLL de gestionnaire de runtime et un ensemble de correctifs de runtime.
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 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.
Une liste d’événements s’affiche. Pour la plupart de ces événements, le mot SUCCESS apparaît 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 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.
Dans le premier problème qui apparaît dans cette image, l’application ne parvient pas à lire à partir du fichier « Config.txt » situé dans le chemin d’accès « C :\Windows\SysWOW64 ». Il est peu probable que l’application tente de référencer ce chemin directement. 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 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.
Le deuxième problème s’affiche dans l’image suivante.
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 fichier 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 ont 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 à 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 à 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), vous trouverez l’outil makeappx.exe sur votre PC Windows 10 : x86 : 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) à démarrer, 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 de 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 en .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 solution ou projet, puis 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 ET fichiers exécutables PSF 32 bits et 64 bits requis au répertoire du package. Inspirez-vous du tableau suivant. Vous devez é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 |
|---|---|
| PSF Lanceur 64.exe | PSF Lanceur 32.exe |
| PSFRuntime64.dll | PSFRuntime32.dll |
| PSFRunDll64.exe | PSFRunDll32.exe |
Votre contenu de package doit maintenant ressembler à ceci.
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 LANCEUR PSF. Si vous connaissez l’architecture de votre application cible, sélectionnez la version appropriée, PSF Lanceur 32.exe ou PSF Lanceur 64.exe. Si ce n’est pas le cas, PSF Lanceur 32.exe fonctionnera dans tous les cas. Prenons 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 fichier 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 :
| Tableau | 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 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 du 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 et processesfixups les clés sont des tableaux. Cela signifie que vous pouvez utiliser le fichier config.json pour spécifier plusieurs applications, processus et DLL 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.
Remarque
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 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 sur 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é des applications empaquetées consiste à utiliser le correctif de trace. Cette DLL est incluse dans 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 config.json, puis empaqueter et installer votre application.
{
"dll": "TraceFixup.dll",
"config": {
"traceLevels": {
"filesystem": "allFailures"
}
}
}
Par défaut, trace Fixup filtre les échecs qui peuvent être considérés comme « attendus ». Par exemple, les applications peuvent essayer de supprimer sans condition un fichier sans case activée pour voir 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. Cela est dû au fait que nous savons d’avant 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 le filtrage 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 ne 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 que précédemment, 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 d’exécution
- Ajouter un projet qui démarre l’exécutable 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 dynamique C++ qui contient une ou plusieurs fonctions de remplacement qui servent de correctif d’exécution. |
| PSF Lanceur | Il s’agit d’un projet vide C++. Ce projet est un endroit où collecter les fichiers distribuables du runtime du Package Support Framework. 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’applications 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 d’exécution
Ajoutez un projet DLL (Dynamic-Link Library) 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 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).
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.
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. 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 Lanceur PSF
Ajoutez un projet de projet vide C++ à la solution.
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é PSFLauncher32 Nom cible sur ou PSFLauncher64 selon 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 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 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 PSF Lanceur et votre projet d’application de bureau, puis cliquez sur le bouton OK.
Remarque
Si vous n’avez pas le code source de votre application, choisissez simplement le projet PSF Lanceur. 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 de package sur Content.
{
"applications": [
{
"id": "",
"executable": "",
"workingDirectory": ""
}
],
"processes": [
{
"executable": "",
"fixups": [
{
"dll": "",
"config": {
}
}
]
}
]
}
Fournissez une valeur pour chaque clé. Utilisez ce tableau comme guide.
| Tableau | 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 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" } ]
}
]
}
Remarque
Les applicationstableaux et processesfixups les clés sont des tableaux. Cela signifie que vous pouvez utiliser le fichier config.json pour spécifier plusieurs applications, processus et DLL 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 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 d’exécution. 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, au lieu d’effectuer l’installation à 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 du 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, dans 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 d’accès 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. Cela est dû au fait que 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étour utilisé par PSF Lanceur.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écuter jusqu’au démarrage et à l’interruption de l’application cible dans le débogueur)
sxe ld fixup.dll
g
(exécutez jusqu’à ce que la DLL de correction soit chargée)
bp ...
Remarque
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 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.
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour