Outils de test et de débogage pour la PLM
L’une des principales différences entre les applications UWP et les applications de bureau traditionnelles est que les applications UWP se trouvent dans un conteneur d’application soumis à la Gestion de la durée de vie des processus (PLM). Les applications UWP peuvent être suspendues, reprises ou arrêtées par le service Runtime Broker sur l’ensemble des plateformes ; des outils dédiés peuvent forcer ces transitions lorsque vous testez ou déboguez le code qui les gère.
Fonctionnalités de Visual Studio 2015
Le débogueur intégré à Visual Studio 2015 peut vous aider à résoudre les problèmes potentiels pouvant survenir lors de l’utilisation des fonctionnalités propres à UWP. Vous pouvez forcer votre application à adapter différents états PLM à l’aide de la barre d’outils Événements de cycle de vie, qui devient visible lorsque vous exécutez et déboguez votre titre.
L’outil PLMDebug
PLMDebug.exe est un outil de ligne de commande qui vous permet de contrôler l’état PLM d’un package d’application ; l’outil est inclus dans le SDK Windows. Après son installation, l’outil se trouve à l’emplacement C:\Program Files (x86) \Windows Kits\10\Debuggers\x64 par défaut.
PLMDebug vous permet également de désactiver les PLM pour un quelconque package d’application installé, ce qui est nécessaire pour certains débogueurs. La désactivation de la Gestion de la durée de vie des processus empêche le service Runtime Broker d’arrêter votre application avant que vous puissiez la déboguer. Pour désactiver la Gestion de la durée de vie des processus, utilisez le commutateur /enableDebug, suivi par le nom complet du package de votre application UWP (le nom court, le nom de famille ou l’AUMID du package ne fonctionneront pas) :
plmdebug /enableDebug [PackageFullName]
Suite au déploiement de votre application UWP à partir de Visual Studio, le nom complet du package s’affiche dans la fenêtre Sortie. Vous pouvez également récupérer le nom complet du package en exécutant Get-AppxPackage dans une console PowerShell.
Vous pouvez éventuellement spécifier un chemin d’accès absolu à un débogueur qui se lance automatiquement lorsque votre package d’application est activé. Si vous souhaitez le faire à l’aide de Visual Studio, vous devez spécifier VSJITDebugger.exe en tant que débogueur. Toutefois, pour utiliser VSJITDebugger.exe, vous devez spécifier le commutateur « -p », ainsi que l’ID du processus (PID) de l’application UWP. Étant donné qu’il est impossible de connaître le PID de votre application UWP au préalable, ce scénario n’est pas réalisable pour l’opération standard.
Vous pouvez contourner cette limitation en écrivant un script ou un outil qui identifie le processus de votre jeu ; l’interpréteur de commandes exécute ensuite VSJITDebugger.exe, en passant le PID de votre application UWP. L’exemple de code C# suivant illustre une approche simple pour y parvenir.
using System.Diagnostics;
namespace VSJITLauncher
{
class Program
{
static void Main(string[] args)
{
// Name of UWP process, which can be retrieved via Task Manager.
Process[] processes = Process.GetProcessesByName(args[0]);
// Get PID of most recent instance
// Note the highest PID is arbitrary. Windows may recycle or wrap the PID at any time.
int highestId = 0;
foreach (Process detectedProcess in processes)
{
if (detectedProcess.Id > highestId)
highestId = detectedProcess.Id;
}
// Launch VSJITDebugger.exe, which resides in C:\Windows\System32
ProcessStartInfo startInfo = new ProcessStartInfo("vsjitdebugger.exe", "-p " + highestId);
startInfo.UseShellExecute = true;
Process process = new Process();
process.StartInfo = startInfo;
process.Start();
}
}
}
Exemple d’utilisation, conjointement avec PLMDebug :
plmdebug /enableDebug 279f7062-ce35-40e8-a69f-cc22c08e0bb8_1.0.0.0_x86__c6sq6kwgxxfcg "\"C:\VSJITLauncher.exe\" Game"
où Game est le nom du processus et 279f7062-ce35-40e8-a69f-cc22c08e0bb8_1.0.0.0_x86__c6sq6kwgxxfcg est le nom complet du package de l’exemple de package d’application UWP.
Notez que chaque appel à /enableDebug doit ensuite être associé à un autre appel PLMDebug avec le commutateur /disableDebug. En outre, le chemin d’accès à un débogueur doit être absolu (les chemins d’accès relatifs ne sont pas pris en charge).