Octobre 2017

Volume 32, numéro 10

Cet article a fait l'objet d'une traduction automatique.

C# - Écrire un plug-in packagé Windows Device Portal

Par Scott Jones

Au milieu du intéressants de la version de Windows 10, une fonctionnalité apportées un débuts silencieux : Portail de périphérique Windows (WDP). WDP est un système de diagnostic basée sur le Web intégré à Windows 10. Après un déploiement progressif, WDP est désormais disponible sur HoloLens, IoT, Mobile, bureau et Xbox. Il devrait être inclus dans les nouvelles versions de Windows qu’ils soient libérés. À l’exception de bureau Windows, WDP est immédiatement disponible prêtes à l’emploi. Sur le bureau, WDP est disponible avec le téléchargement et l’installation du package en Mode développeur de mise à jour Windows facultatif. Dans cet article, j’allons vous montrer comment utiliser l’API WDP pour implémenter un WDP empaquetée plug-in d’étendre votre application du Windows Store avec l’API REST personnalisées. Tandis que le focus de cet article est sur le bureau Windows, les concepts et techniques s’appliquent également aux autres éditions de Windows.

Pour créer et exécuter un WDP empaquetée plug-in, vous devez mettre à jour votre système doit au moins 10 créateurs de mise à jour Windows (10.0.15063.0) et installez le SDK Windows 10 correspondant (bit.ly/2tx5Bnk). Pour obtenir des instructions détaillées, consultez l’article « Mise à jour vos outils pour Windows 10 créateurs de mise à jour » (bit.ly/2tx3FeD). Il peut être nécessaire de redémarrer l’ordinateur pour Visual Studio détecter et prendre en charge le nouveau SDK ; Sinon, les projets peuvent échouer à charger.

Si vous n’êtes pas familiarisé avec WDP, nous vous invitons à lire l’article, « Présentation du portail de périphérique Windows » (bit.ly/2uG9rco). Cela fournit une introduction aux fonctionnalités de WDP et garantit également que vous avez installé avant de procéder à l’écriture d’un package plug-in. 

Brièvement, vous devez télécharger et installer le package de Mode développeur facultatif. À partir de l’application de paramètres (appuyez sur la touche Windows + I), accédez à la mise à jour et sécurité | Pour les développeurs et sélectionnez le mode développeur case d’option. Lors de l’installation du package Mode développeur est terminée, vérifiez la case à cocher Activer le portail appareil, les informations d’identification définies comme vous le souhaitez et accédez à l’URL fournie pour vérifier la fonctionnalité. Une fois en acceptant la WDP un certificat auto-signé et entrer les informations d’identification, le navigateur doit afficher l’interface utilisateur Web de WDP, comme indiqué dans Figure 1.

Figure 1 Windows appareil portail interface utilisateur Web

Architecture WDP

Les outils présentés dans la UI WDP dans Figure 1 sont implémentés avec des contrôles JavaScript qui communiquent avec les API REST hébergée dans le Service WDP. En tant qu’API REST, ces demandes généralisées et sans état sont applicables dans les contextes plus que simplement l’UI WDP. Par exemple, une API REST de WDP peut être appelée à partir d’un script Windows PowerShell ou d’un agent utilisateur personnalisée. Le WindowsDevicePortalWrapper (bit.ly/2tx2NXF) projet open source propose une bibliothèque pour le développement des agents utilisateur WDP personnalisés en c#.  Dans cet article, je vais utiliser le navigateur et le curl gratuitement l’utilitaire de ligne de commande (curl.haxx.se) pour exercer mon API REST personnalisées.

Extensibilité WDP a été conçu. Par exemple, WDP personnalisé pour chaque édition de Windows via des plug-ins. Avec la mise à jour Windows 10 créateurs, il est possible pour des tiers d’étendre WDP en créant des plug-ins de packages. Un package plug-in fournit des points de terminaison REST personnalisés, avec une option basée sur le Web interface utilisateur, implémentée et déployée dans une application Windows Store. Figure 2 illustre le fonctionnement du système.

Figure 2 Architecture portail du périphérique Windows

Lecteurs familiarisés avec les mécanismes internes de va IIS de Microsoft reconnaissent la conception de WDP. Comme avec IIS, WDP est basé sur l’API du serveur HTTP (également appelé HTTP. (SYS), division des responsabilités entre les rôles de contrôleur HTTP et le travail de HTTP. Le service WDP implémente le contrôleur en cours d’exécution sous le compte système local. Chaque WDP empaquetées plug-in implémente un processus de travail, qui s’exécutent dans le bac à sable AppContainer dans le contexte de sécurité de l’utilisateur. 

Il est possible d’héberger un serveur Web à partir de zéro au sein d’une application de store, à l’aide de l’API du serveur HTTP. Toutefois, mise en œuvre un WDP empaquetées plug-in offre plusieurs avantages. WDP fournit des services de chiffrement, l’authentification et la sécurité pour tout le contenu et les API REST, y compris celles figurant dans les plug-ins. Cela inclut la protection contre la falsification de requête et WebSocket intersites attaques de piratage. En outre, WDP gère la durée de vie de chaque empaquetées plug-in, ce qui peut s’exécuter soit une application visible par l’interface utilisateur de premier plan ou sous la forme d’une tâche en arrière-plan. En bref, il est plus simple et plus sûre implémenter les API REST d’avec un package plug-in. Le diagramme de séquence dans Figure 3 illustre le flux d’exécution pour un package de plug-in.

L’Activation de la figure 3 et exécution d’un package de plug-in

Dans son application de package manifeste, chaque plug-in s’identifie avec une extension d’application windows.devicePortalProvider et le service d’applications associées et déclare ses itinéraires (URL) d’intérêt. Un plug-in peut inscrire un itinéraire de contenu, un itinéraire de l’API REST ou les deux. Au moment d’installation de package, les données de manifeste sont inscrit avec le système.

Au démarrage, le service WDP analyse le système pour les plug-ins inscrits WDP empaqueté, telles qu’identifiées par l’extension d’application windows.devicePortalProvider. Pour chaque plug-in de découverte, le service WDP lit le manifeste du package pour les informations d’itinéraire. L’ensemble des itinéraires demandés par le package de plug-in, appelés le URLGroup, est enregistré avec HTTP. SYS pour créer une file d’attente à la demande HTTP. Le service WDP contrôle ensuite chaque file d’attente de demandes de plug-in package pour les demandes entrantes.

À la première demande d’itinéraire pour un plug-in, le service WDP lance un sponsor WDP dans le contexte de sécurité de l’utilisateur. Le promoteur WDP active à son tour le package plug-in, le transfert de la file d’attente de la demande HTTP pour le plug-in.  Le service WDP active et communique avec le package indiqué plug-in via le service d’application dans le manifeste. Les fonctions de connexion de service application comme un canal nommé, avec le commanditaire WDP agissant en tant que le client de cette connexion et le package du plug-in en tant que le serveur. Cette conception sponsoring garantit que les requêtes longues ne sont pas interrompus par les stratégies de gestion des ressources du système. Le runtime WDP commence ensuite traiter les demandes pour le compte du plug-in.  Demandes de contenu sont traitées automatiquement, tandis que les requêtes d’API REST sont distribuées au gestionnaire d’événements du package plug-in RequestReceived inscrit. Durée de vie du plug-in est gérée par le service WDP et le Gestionnaire de durée de vie des processus (PLM). Pour plus d’informations sur la gestion de l’état de plug-in lorsqu’une tâche en arrière-plan est suspendue, consultez l’article, « Lancement, reprise et les tâches en arrière-plan » (bit.ly/2u0N7fO). Un objet de traitement supplémentaire garantit que les arrêt du service WDP est terminée, fin d’exécution tout en cours d’exécution WDP sponsors leur sont associées empaquetées et plug-ins.

L’écriture d’un package plug-in

Créer le projet avant de créer votre package plug-in, vous devez décider si votre gestionnaire de requêtes Web peut s’exécuter comme une tâche en arrière-plan ou si elle doit s’exécuter en cours d’une application de premier plan. L’exécution de premier plan est nécessaire si, par exemple, le gestionnaire requiert un accès aux structures de données internes de l’application. Cette flexibilité dans l’exécution est activée par le service d’applications sous-jacent, qui peut être configuré pour l’opération en arrière-plan ou au premier plan. Pour une discussion plus approfondie de AppServices, veuillez consulter les articles, « Créer et consommer d’un Service App » (bit.ly/2uZsSfz) et « Convertir une application Service à exécuter dans le même processus en tant que son hôte application » (bit.ly/ 2u0G8n1).

Dans cet exemple, vous allez implémenter un gestionnaire de premier plan et un gestionnaire d’arrière-plan et illustrer l’intégration de votre contenu statique et l’API REST. Commencez par créer une nouvelle solution dans Visual Studio avec le modèle de projet application vide (Windows universel) c#. Nom de la solution MyPackagedPlugin et le projet MyApp. L’application hébergera le Gestionnaire de premier plan.  Lorsque vous y êtes invité, cibler au moins mise à jour de kit de développement logiciel du créateur (15063), pour garantir la disponibilité de l’API WDP. Ensuite, ajoutez une bibliothèque de composant d’exécution à la solution, à l’aide du modèle Windows Runtime composant Visual c#. Nom de ce projet MyComponent. Cette bibliothèque hébergera le Gestionnaire d’arrière-plan. 

Pour vous assurer que le composant est inclus dans le package d’application, ajoutez une référence à celle-ci dans le projet d’application. Dans l’Explorateur de solutions, développez le nœud de projet d’application, cliquez sur le nœud Références et choisissez Ajouter une référence. Dans la boîte de dialogue Gestionnaire de références, développez le nœud projets, sélectionnez la Solution et archiver le projet MyComponent.

Avant de continuer, définissez la plateforme de solution pour correspondre à l’architecture de votre machine. Il s’agit d’une exigence pour un package de plug-in, WoW64 n’est pas prise en charge. Notez que dans ce cas, je déploie sur l’ordinateur local, mais l’avis s’applique également lors du déploiement sur un appareil cible secondaire.

Modifier le manifeste, car il sont un nombre de modifications du manifeste nécessaires, vous allez modifier le fichier Package.appxmanifest directement, au lieu d’utiliser le concepteur. Dans l’Explorateur de solutions, sous le nœud de l’application, avec le bouton droit sur le nœud de fichier Package.appxmanifest et choisissez d’afficher le Code pour modifier le code XML.

Commencez par ajouter les uap4 et les déclarations d’espace de noms rescap et les alias qui seront nécessaires pour les éléments suivants :

<Package ... 
  xmlns:uap4="https://schemas.microsoft.com/appx/manifest/uap/windows10/4"
  xmlns:rescap="https://schemas.microsoft.com/appx/manifest/foundation
    /windows10/restrictedcapabilities"
  IgnorableNamespaces="... uap4 rescap">

Pour rendre le package plus détectable pendant le débogage, je vais modifier le nom du package à partir d’un GUID généré par un nom explicite :

<Identity Name="MyPackagedPlugin" Publisher="CN=msdn" Version="1.0.0.0" />

Ensuite, je vais ajouter les extensions d’application requises pour chaque gestionnaire de plug-in empaquetée à l’élément package\applications\application\extensions, comme indiqué dans Figure 4. 

Figure 4 Ajout d’Extensions d’application

<Package ...><Applications><Application ...>

  <Extensions>
        
    <!--Foreground (in app) packaged plug-in handler app service and WDP provider-->
    <uap:Extension 
      Category="windows.appService">
      <uap:AppService Name="com.contoso.www.myapp" />
    </uap:Extension>
    <uap4:Extension 
      Category="windows.devicePortalProvider">
      <uap4:DevicePortalProvider 
        DisplayName="MyPluginApp" 
        AppServiceName="com.contoso.www.myapp"
        ContentRoute="/myapp/www/" 
        HandlerRoute="/myapp/API/" />
    </uap4:Extension>
            
    <!--Background packaged plug-in handler app service and WDP provider-->
    <uap:Extension 
      Category="windows.appService" 
      EntryPoint="MyComponent.MyBackgroundHandler">
      <uap:AppService Name="com.contoso.www.mycomponent" />
    </uap:Extension>
    <uap4:Extension 
      Category="windows.devicePortalProvider">
      <uap4:DevicePortalProvider 
        DisplayName="MyPluginComponent" 
        AppServiceName="com.contoso.www.mycomponent"
        HandlerRoute="/mycomponent/API/" />
    </uap4:Extension>
   
  </Extensions>

</Application></Applications></Package>

Chaque gestionnaire requiert que les deux extensions. L’extension de service d’applications fournit le canal de communication et le mécanisme d’activation entre le service WDP et runtime WDP hébergeant le gestionnaire. Par convention, AppServices utilise un modèle de nom de domaine inverse pour garantir l’unicité. Si vous implémentez un service d’applications en arrière-plan, l’attribut de point d’entrée est obligatoire et spécifie où commence l’exécution. Si vous implémentez un service d’applications de premier plan, l’exécution commence par la méthode OnBackgroundActivated de l’application et l’attribut de point d’entrée est omis.

L’extension DevicePortalProvider fournit des données de configuration pour la DevicePortalConnection qui héberge le gestionnaire. Un DevicePortalProvider représente le côté client de la connexion de service d’applications, en fournissant des gestionnaires d’URL pour la DevicePortalConnection. L’attribut AppServiceName doit correspondre à l’attribut de nom de l’élément de service d’applications (par exemple, com.contoso.www.myapp). L’élément DevicePortalProvider peut spécifier un ContentRoute pour traiter du contenu Web statique ; un HandlerRoute pour la distribution des demandes à un gestionnaire d’API REST ; ou les deux. ContentRoute et HandlerRoute doivent être unique. Si soit acheminer est en conflit avec un itinéraire WDP intégré ou un itinéraire de plug-in package précédemment enregistré, le plug-in ne sera pas chargé, présenter un message de diagnostic approprié. En outre, l’URL relative doit pointer vers un chemin d’accès relatif sous le package de ContentRoute dossier d’installation (par exemple, \myapp\www). Pour plus d’informations, consultez la spécification d’Extension DevicePortalProvider (bit.ly/2u1aqG8).

Enfin, je vais ajouter les fonctionnalités nécessaires pour mon package plug-in :

<Capabilities>
  <Capability Name="privateNetworkClientServer" />
  <rescap:Capability Name="devicePortalProvider" />
</Capabilities>

La fonctionnalité privateNetworkClientServer permet de HTTP. Fonctionnalité SYS dans une AppContainer. Dans cette démonstration, vous allez déployer le package directement à partir de Visual Studio sur l’ordinateur local pour l’exécution.  Toutefois, pour intégrer votre application dans le magasin, vous également devrez obtenir la fonction devicePortalProvider, qui est restreinte aux partenaires Microsoft. Pour plus d’informations, reportez-vous à l’article, « Déclarations des fonctionnalités d’application » (bit.ly/2u7gHkt). Ces fonctionnalités sont le minimum requis par le runtime WDP pour héberger un package plug-in. Code de gestionnaire de votre plug-in peut nécessiter des fonctionnalités supplémentaires, en fonction de l’API de plateforme Windows universelles qu’elle appelle. 

Ajout de statique contenu suivant, nous allons créer une page d’état du plug-in. La page et tout autre contenu statique, qu'il fait référence, doivent être placés dans un chemin d’accès relatif de l’application correspondant à l’itinéraire contenu réservé pour le plug-in, dans ce cas, /myapp/www. Dans l’Explorateur de solutions, avec le bouton droit sur le nœud de votre projet d’application et sélectionnez Ajouter | Nouveau dossier. Nom du dossier myapp. Avec le bouton droit sur le nœud de dossier qui vient d’être ajouté et sélectionnez à nouveau les ajouter | Nouveau dossier pour créer un sous-dossier nommé www. Appuyez sur Ctrl + N, puis dans la boîte de dialogue Nouveau fichier, sélectionnez Général | Modèle de HTML Page. Enregistrez ce fichier sous index.html, sous le chemin d’accès de la solution MyPackagedPlugin\MyApp\myapp\www. Ajoutez ensuite ce fichier pour le chemin d’accès de dossier de projet, afin qu’il a inclus en tant que contenu du package. Avec le bouton droit sur le nœud du fichier index.html nouvellement ajoutée, puis sélectionnez Propriétés. Vérifiez les valeurs de propriété par défaut de l’Action de génération : Contenu et copiez dans répertoire de sortie : Ne pas copier.

Ajoutez maintenant le balisage indiqué dans Figure 5 vers le index.html nouvellement créé. Cette page montre plusieurs choses. Tout d’abord, notez que les ressources WDP intégrées, telles que les bibliothèques jquery.js et rest.js, sont disponibles pour créer des packages plug-ins, ainsi. Cela permet à un package plug-in pour combiner les fonctionnalités spécifiques à un domaine avec fonctionnalité WDP intégrée. Pour plus d’informations, consultez l’article, « Référence de l’API appareil Portal » (bit.ly/2uFTTFD). En second lieu, notez la référence pour appels d’API REST, /myapp/API/status de l’application et /mycomponent/API/status du composant du plug-in.  Cela montre comment contenu statique et dynamique d’un plug-in peut être facilement combiné. 

Balisage de la Page état figure 5

<html>
<head>
  <title>My Packaged Plug-in Page</title>
  <script src="/js/rest.js"></script>
  <script src="/js/jquery.js"></script>
  <script type="text/javascript">
    function InitPage() {
      var webb = new WebbRest();
      webb.httpGetExpect200("/myapp/API/status")
        .done(function (response) {
          $('#app_status')[0].innerText = response.status;
        });
      webb.httpGetExpect200("/mycomponent/API/status")
        .done(function (response) {
          $('#comp_status')[0].innerText = response.status;
        });
    }
  </script>
</head>
<body onload="InitPage();">
  <div style="font-size: x-large;">
    My Packaged Plug-in Page
    <br/><br/>
    App Status:&nbsp;<span id="app_status" style="color:green"></span>
    <br/>
    Component Status:&nbsp;<span id="comp_status" style="color:green"></span>
  </div>
</body>
</html>

Ajout d’une API REST maintenant vous allez implémenter un gestionnaire de l’API REST. Comme mentionné précédemment, le choix du point d’entrée dépend de si un arrière-plan ou un premier plan app service est implémenté. Au-delà d’une petite différence au niveau de mode d’obtention de la connexion de Service d’application entrants, l’implémentation de la connexion du portail périphérique est identique pour les deux scénarios. Vous allez commencer avec le Gestionnaire de premier plan de l’application.

Ouvrez le fichier source App.xaml.cs et ajoutez les espaces de noms suivants, requis pour chaque gestionnaire :

using Windows.ApplicationModel.AppService;
using Windows.ApplicationModel.Background;
using Windows.System.Diagnostics.DevicePortal;
using Windows.Web.Http;
using Windows.Web.Http.Headers;

À l’intérieur de la définition de classe MyApp.App, je vais ajouter quelques membres pour implémenter les état du gestionnaire.  BackgroundTaskDeferral diffère que l’exécution d’ordinateurs hôtes du Gestionnaire d’achèvement de la tâche en arrière-plan et DevicePortalConnection implémente la connexion au service WDP lui-même.

sealed partial class App : Application
{
  private BackgroundTaskDeferral taskDeferral;
  private DevicePortalConnection devicePortalConnection;
  private static Uri statusUri = new Uri("/myapp/API/status", UriKind.Relative);

Ensuite, substituez le Gestionnaire d’activation en arrière-plan pour l’application, pour instancier une DevicePortalConnection et de s’abonner à ses événements, comme indiqué dans Figure 6.

Figure 6 implémentation de la DevicePortalConnection

// Implement background task handler with a DevicePortalConnection
protected override void OnBackgroundActivated(BackgroundActivatedEventArgs args)
{
  // Take a deferral to allow the background task to continue executing 
  var taskInstance = args.TaskInstance;
  this.taskDeferral = taskInstance.GetDeferral();
  taskInstance.Canceled += TaskInstance_Canceled;

  // Create a DevicePortal client from an AppServiceConnection 
  var details = taskInstance.TriggerDetails as AppServiceTriggerDetails;
  var appServiceConnection = details.AppServiceConnection;
  this.devicePortalConnection = 
    DevicePortalConnection.GetForAppServiceConnection(
      appServiceConnection);

  // Add handlers for RequestReceived and Closed events
  devicePortalConnection.RequestReceived += DevicePortalConnection_RequestReceived;
  devicePortalConnection.Closed += DevicePortalConnection_Closed;
}

Pour ce gestionnaire, je vais simplement chercher les demandes aux URI /myapp/API/status et répondre avec une structure JSON, comme indiqué dans Figure 7. Une implémentation plus complexe peut prend en charge plusieurs itinéraires, faire la distinction entre Obtient et les billets, inspecter les paramètres d’URI et ainsi de suite.

Figure 7 gère la requête

// RequestReceived handler demonstrating response construction, based on request
private void DevicePortalConnection_RequestReceived(
  DevicePortalConnection sender, 
  DevicePortalConnectionRequestReceivedEventArgs args)
{
  if (args.RequestMessage.RequestUri.AbsolutePath.ToString() == 
    statusUri.ToString())
  {
    args.ResponseMessage.StatusCode = HttpStatusCode.Ok;
    args.ResponseMessage.Content = 
      new HttpStringContent("{ \"status\": \"good\" }");
    args.ResponseMessage.Content.Headers.ContentType = 
      new HttpMediaTypeHeaderValue("application/json");
  }
  else
  {
    args.ResponseMessage.StatusCode = HttpStatusCode.NotFound;
  }
}

Enfin, gérer la fermeture de la DevicePortalConnection, soit directement avec son événement fermé, soit indirectement par l’annulation de la tâche en arrière-plan, comme indiqué dans Figure 8.

La figure 8, la fermeture de la DevicePortalConnection

// Complete the deferral if task is canceled or DevicePortal connection closed
private void Close()
{
  this.devicePortalConnection = null;
  this.taskDeferral.Complete();
}

private void TaskInstance_Canceled(IBackgroundTaskInstance sender, 
  BackgroundTaskCancellationReason reason)
{
  Close();
}

private void DevicePortalConnection_Closed(DevicePortalConnection sender, 
  DevicePortalConnectionClosedEventArgs args)
{
  Close();
}

Implémentation de gestionnaire d’arrière-plan du projet de composant est presque identique à l’exemple de premier plan. Ouvrez le fichier source Class1.cs et ajouter les espaces de noms requis, comme précédemment. À l’intérieur de l’espace de noms de composant, remplacez la définition de la classe générée avec une classe qui implémente IBackgroundTask et sa méthode Run requis : 

public sealed class MyBackgroundHandler : IBackgroundTask
{
  public void Run(IBackgroundTaskInstance taskInstance)
  {
    // Implement as for foreground handler's OnBackgroundActivated...
  }
}

La méthode Run prend une valeur de paramètre IBackgroundTaskInstance directement. Rappelez-vous que le Gestionnaire de premier plan obtenu cette valeur à partir du membre TaskInstance du paramètre BackgroundActivatedEventArgs de OnBackgroundActivated. À part cette différence de l’obtention de la taskInstance, l’implémentation est identique pour les deux gestionnaires. Copiez l’implémentation restante à App.xaml.cs partir de votre gestionnaire de premier plan.

Un package de test plug-in

Déploiement de plug-in pour tester votre plug-in, vous devez tout d’abord le déployer, via le déploiement de Visual Studio F5 ou à l’aide des fichiers .aspx libre (généré par le projet Visual Studio | Magasin | Créer des Packages d’application menu). Nous allons utiliser la première. Avec le bouton droit sur le nœud de projet MyApp et sélectionnez Propriétés. Dans la feuille de propriétés de projet, sélectionnez l’onglet débogage et puis activer l’option ne lance pas la case à cocher.

Je vous suggère de définir un point d’arrêt dans votre gestionnaire d’événements RequestReceived et, éventuellement, dans le point d’entrée de votre plug-in, votre gestionnaire d’événements BackgroundActivated ou de la méthode Run substituer. Cela confirme que votre plug-in est correctement configuré et activation correctement lorsque vous le testez dans la section suivante.  Maintenant, appuyez sur F5 pour déployer et déboguer votre application.

WDP en cours d’exécution dans le débogage en Mode après l’avoir déployé votre package, WDP doit être redémarré pour le détecter. (Dans le cas où vous avez ignoré la présentation WDP mentionnée précédemment, vous devez également installer le package de Mode développeur maintenant pour vérifier que WDP est disponible). Cela est possible en activant la case à cocher Activer le portail appareil à partir de l’application de paramètres de mise à jour et de sécurité | Pour la page de développeurs. Toutefois, je vais plutôt exécuter le Service de WDP en mode débogage tant qu’application console. Cela permettra à la sortie de trace WDP, qui seront utiles lors de la résolution des problèmes de l’exécution et de la configuration de plug-in package. Le service WDP est configuré pour s’exécuter sous le compte système, et il est également nécessaire lors de l’exécution WDP en mode débogage. L’utilitaire de PsExec, disponible dans le cadre de la suite PsTools (bit.ly/2tXiDf4), aidera à le faire.

Commencez par créer une console système, en cours d’exécution PsExec à partir d’une console administrateur :

> psexec -d -i -s -accepteula cmd /k title SYSTEM Console - Careful!

Cette commande lance une deuxième fenêtre de console en cours d’exécution dans le contexte du compte système. Normalement, cette fenêtre utilise la console héritée, et les nouvelles fonctionnalités de console, notamment habillage du texte sur le redimensionnement, des améliorations de la sélection de texte et des raccourcis du Presse-papiers, ne sont pas disponibles. Si vous souhaitez activer ces fonctionnalités lors de l’exécution en tant que système, enregistrez ce qui suit dans un fichier de script de Registre (par exemple, EnableNewConsoleForSystem.reg) et exécutez-le :

Windows Registry Editor Version 5.00

[HKEY_USERS\.DEFAULT\Console]
"ForceV2"=dword:00000001

Dans la console système, exécutez WDP en mode débogage, permettant ainsi aux demandes claire et chiffrées : 

> webmanagement -debug -clearandssl

Vous devez voir une sortie similaire à celle de Figure 9.  Pour arrêter en toute sécurité WDP en mode débogage, appuyez sur Ctrl + C. Ceci permet de conserver votre console système afin que vous pouvez itérer sur le développement de plug-in. 

Figure 9 Portal de périphérique Windows en Mode débogage

Notez que la sortie de trace utilise différents termes : gestion Web, WebB et WDP. Ces existent pour des raisons historiques et faire référence aux différents sous-systèmes, mais les distinctions peuvent être ignorées. Notez également que l’exécution en mode débogage utilise une configuration différente de l’exécution en tant que service. Par exemple, en mode débogage, les autorisations par défaut sont désactivée par défaut. Cela évite d’avoir à entrer les informations d’identification et empêche HTTPS automatique la redirection, ce qui simplifie les tests à partir d’un navigateur ou l’utilitaire de ligne de commande. En outre, les ports ont été assignés valeurs 54321 et 54684. Normalement, le service WDP bureau utilise les ports 50080 et 50443 (bien que si elles sont effectuées, ports aléatoires seront affectées dynamiquement). Cela permet à exécuter en mode débogage sans interférer avec le mode de production de WDP WDP en cours d’exécution en tant que service. Toutefois, il peut s’avérer préjudiciables basculer les numéros de port sur les URL lors du test, en fonction du mode WDP d’exécution. Dans ce cas, vous pouvez utiliser les options de ligne de commande - httpPort et - httpsPort pour définir explicitement les numéros de port pour faire correspondre le mode de production. Dans ce cas, vous devez vous assurer que le service WDP est désactivé pour éviter les conflits. Pour afficher toutes les options de ligne de commande WDP, tapez :

> WebManagement.exe- ?

Comme indiqué dans la sortie de trace, plusieurs des plug-ins sont chargés automatiquement dans le cadre du démarrage WDP. WDP puis la détection de la version déployée empaquetée plug-in avec les rapports « trouvée 2 packages » (plus précisément, un package avec deux fournisseurs). Le premier fournisseur décrit le Gestionnaire de premier plan, confirme la réservation de l’URL ContentRoute statique et son chemin d’accès du fichier de package et reste HandlerRoute. À ce stade, WDP a créé une file d’attente de demandes HTTP à la demande pour ces itinéraires de service et est en attente de demandes. Le deuxième fournisseur décrit le Gestionnaire d’arrière-plan, qui spécifie uniquement une HandlerRoute REST. Il, est prêt pour l’entreprise.

L’exécution du plug-in est recommandé de développer et tester votre plug-in avec l’utilitaire de ligne de commande excellent indiqué précédemment, curl. Pour les scénarios plus simples, un navigateur est adéquat, mais curl offre un contrôle affiné sur les en-têtes, l’authentification et ainsi de suite. Cela rend plus facile à utiliser lorsque le chiffrement WDP, l’authentification et les options de protection CSRF sont activées. Dans ces situations, le curl », détaillée » option est également utile pour le dépannage.

La figure 10 montre comment demander les ressources du Gestionnaire de premier plan : son état API REST et la page Web. 

La figure 10 tests avec Curl

Figure 11 affiche l’aide du navigateur pour demander la page d’état de l’application, à son tour montrant l’embedded appelle d’API REST.

Figure 11 test avec le navigateur

Lorsque toutes les demandes sont apportées aux itinéraires de votre plug-in, le point d’arrêt que vous définissez dans votre point d’entrée doit atteint dans le débogueur. Et pour les demandes de l’API REST en particulier, le point d’arrêt dans votre gestionnaire d’événements RequestReceived devez atteindre. Vous devez également voir confirmation dans le diagnostic WDP de sortie que le package plug-in a été activé.

Dépannage Il est important de noter quelques exemples d’empêchent l’exécution correcte d’un gestionnaire d’erreurs courantes :

• Incompatibilités de manifeste comme point d’entrée ou le nom de service d’applications
• Omettant d’ajouter une référence de projet de composant de gestionnaire d’arrière-plan à l’application
• Déploiement avec une incompatibilité d’architecture entre le package et le service
• Mise en œuvre IBackgroundTask dans votre projet d’application, plutôt que comme un composant Windows Runtime

Lors de l’exécution en mode débogage, WDP fournira des messages de diagnostic spécifiques de ces erreurs, lorsque cela est possible. Après que trois tentatives infructueuses pour activer un plug-in, WDP désactive le plug-in pour cette session comme indiqué avec les tests de diagnostic :

WDP Packaged Plugin: Disabling request queue after 3 failed attempts

Après avoir apporté des corrections à votre code ou le manifeste du package, il est généralement nécessaire de redémarrer WDP, pour réinitialiser le compteur désactivé et les modifications de configuration de package.

Pour résumer

L’API du portail de périphérique Windows propose un mécanisme de sécurisée et simple permettant d’étendre les fonctionnalités des diagnostics de votre application du Windows Store avec empaquetée plug-ins. Futures améliorations dont cette API permet d’intégrer des plug-ins empaquetées dans l’UI WDP, introduire des API REST pour l’installation et de contrôle de plug-ins empaquetées et développer les applications possibles pour les plug-ins.

Scott Jones travaille pour Microsoft en tant qu’un ingénieur du logiciel de l’équipe de la plate-forme d’Application et les outils.

Merci à l'expert technique Microsoft suivant d'avoir relu cet article :  Hirsch Cordani

Discussion sur cet article sur le forum MSDN Magazine