Share via



Oktober 2017

Band 32, Nummer 10

Dieser Artikel wurde maschinell übersetzt.

C#: Schreiben eines Windows Device Portal-Paket-Plug-Ins

Durch Scott Jones

Inmitten der ersten von der Version von Windows 10 erstellt eine Funktion eine stille erstmals: Windows-Geräteportal (WDP). WDP ist eine webbasierte Diagnosesystem in Windows 10 erstellt. Nach einer schrittweisen Rollout ist WDP nun auf HoloLens IoT "," Mobile "," Desktop "und" Xbox verfügbar. Sie erwarten in neuen Versionen von Windows enthalten sein, wie sie freigegeben werden. Mit Ausnahme von Windows-Desktop ist WDP sofort verfügbar ist, ausgegeben. Auf dem Desktop ist WDP mit Download und Installation des optionalen Pakets Entwicklermodus für Windows Update verfügbar. In diesem Artikel zeige ich Ihnen wie die WDP-API zu verwenden, um eine WDP verpackt implementieren-Plug-in Windows Store-app mit benutzerdefinierten REST-APIs zu erweitern. Während der Schwerpunkt dieses Artikels auf dem Windows-Desktop befindet, gelten sich die Konzepte und Techniken auch für andere Editionen von Windows.

Erstellen und Ausführen einer verpackt WDP-Plug-in, müssen Sie Ihre Systemupdates mindestens auf das Windows 10 Ersteller Update (10.0.15063.0), und installieren Sie das entsprechende Windows 10-SDK (bit.ly/2tx5Bnk). Ausführliche Anweisungen finden Sie im Artikel "Aktualisieren der Tooling für Windows 10 Ersteller Update" (bit.ly/2tx3FeD). Es kann erforderlich sein, starten Sie den Computer für Visual Studio zu erkennen und das neue SDK zu unterstützen; Andernfalls können Projekte nicht geladen.

Wenn Sie nicht mit WDP vertraut sind, sollten Sie den Artikel "Windows-Gerät-Portal (Übersicht)" zu lesen (bit.ly/2uG9rco). Dies bietet eine Einführung in die Funktionen von WDP und wird auch sichergestellt, darin, dass Sie installiert ist, bevor Sie den Vorgang fortsetzen, für das Schreiben einer App-Plug-in. 

Kurz gesagt müssen Sie zum Herunterladen und installieren das optionale Entwicklermodus-Paket. Vom Einstellungs-app (drücken Sie Windows + I), navigieren Sie zu dem Update und Sicherheit | Seite "Entwickler", und wählen den Entwicklermodus Optionsfeld. Klicken Sie nach Abschluss die Paketinstallation Entwicklermodus Kontrollkästchen Sie Device-Portal aktivieren, legen Sie die Anmeldeinformationen als gewünscht, und navigieren Sie zu der angegebenen URL aus, um die Funktionalität zu überprüfen. Nach dem Akzeptieren der WDP Zertifikat selbstsignierte und Eingeben von Anmeldeinformationen, im Browser die WDP-Webbenutzeroberfläche angezeigt sollte, entsprechend Abbildung 1.

Windows-Gerät Portal Webbenutzeroberfläche

Abbildung 1 Windows-Gerät Portal Web-Benutzeroberfläche

WDP-Architektur

Die Tools angezeigt, in der UI WDP in Abbildung 1 mit JavaScript-Steuerelementen, die Kommunikation mit REST-APIs, die in der WDP-Dienst gehostet implementiert werden. Als REST-APIs können diese generalisierten, statuslose webanforderungen in mehrere Kontexte als nur die WDP UI angewendet werden. Beispielsweise könnte eine WDP-REST-API von Windows PowerShell-Skript oder eine benutzerdefinierte Benutzer-Agent aufgerufen werden. Die WindowsDevicePortalWrapper (bit.ly/2tx2NXF) open Source-Projekte bietet eine Bibliothek für die Entwicklung von benutzerdefinierten WDP Benutzer-Agents in C# geschrieben.  In diesem Artikel verwenden ich dem Browser und den freien Befehlszeilen-Hilfsprogramm Curl (curl.haxx.se), um Meine benutzerdefinierte REST-APIs verwenden.

WDP wurde mit Erweiterbarkeit ausgelegt. Beispielsweise wird WDP für jede Edition von Windows über den integrierten Plug-Ins angepasst. Mit dem Windows 10-Ersteller-Update ist es möglich, dass Dritte WDP können durch Erstellen von App-Plug-ins erweitert werden. Eine gepackte-Plug-in bietet benutzerdefinierte REST-Endpunkte mit einer optionalen webbasierte Benutzeroberfläche, implementiert und innerhalb einer Windows Store-Apps bereitgestellt. Abbildung 2 veranschaulicht, wie das System funktioniert.

Windows-Gerät-Portal-Architektur

Abbildung 2 Windows-Gerät-Portal-Architektur

Leser, die mit der internen Mechanismen von Microsofts IIS wird vertraut erkennt das Design der WDP. Wie bei IIS, basiert die WDP auf die HTTP-Server-API (auch als HTTP bezeichnet. (SYS), unterteilen Aufgaben zwischen den HTTP-Controller und HTTP-Worker-Rollen. Der WDP-Dienst implementiert, den Controller an, unter dem lokalen Systemkonto ausgeführt wird. Jede WDP verpackt-Plug-in implementiert einen Worker in den Sandkasten AppContainer im Sicherheitskontext des Benutzers ausgeführt wird. 

Es ist möglich, einen Webserver von Grund auf neu innerhalb einer Store-app, die mithilfe der HTTP-Server-API zu hosten. Allerdings verpackt, implementieren eine WDP-Plug-in bietet mehrere Vorteile. WDP bietet Verschlüsselung, Authentifizierung und Sicherheit der Dienste für alle Inhalte und REST-APIs, einschließlich jener in den App-Plug-ins. Dies schließt Schutz von websiteübergreifenden anforderungsfälschungen und siteübergreifende WebSocket-hijacking-Angriffe. Darüber hinaus WDP verwaltet die Lebensdauer von jeder verpackt-Plug-Ins, die möglicherweise über eine Benutzeroberfläche sichtbar Vordergrund-app oder als ein Hintergrundtask ausgeführt werden. Kurz gesagt, ist es einfacher und sicherer zu REST-APIs mit einem App-Plug-in implementieren. Das Sequenzdiagramm in Abbildung 3 veranschaulicht den Fluss der Ausführung für eine App-Plug-in.

Aktivierung und Ausführung von einem App-Plug-in

Abbildung 3-Aktivierung und Ausführung von einem App-Plug-in

In der Paket-app-Manifest jedes plug-in identifiziert sich selbst mit einem windows.devicePortalProvider-app-Erweiterung und die zugehörigen Anwendungsdienst und deklariert seine Routen (URLs) von Interesse sind. Plug-in kann eine Content Route, eine Route für die REST-API oder beides zu registrieren. Zur Installation des Pakets werden das Manifesten Daten im System registriert.

Beim Start wird das System wird für registrierte WDP verpackt-Plug-ins, von der WDP-Dienst überprüft, das durch die windows.devicePortalProvider-app-Erweiterung. Für jedes plug-in ermittelt, liest der Dienst WDP Paketmanifest für Routeninformationen. Der Satz von Routen, die von der App-Pakete angefordert-Plug-in, als die URLGroup bezeichnet ist mit HTTP registriert. SYS um eine bedarfsgesteuerte HTTP-Anforderungswarteschlange zu erstellen. Der WDP-Dienst überwacht dann jede gepackte-Plug-in Warteschlange für eingehende Anforderungen.

An die erste routenanforderung für ein plug-in startet der Dienst WDP WDP Sponsor im Sicherheitskontext des Benutzers. Der WDP Sponsor aktiviert wiederum die gepackte-Plug-in die Warteschlange der HTTP-Anforderung an das plug-in übertragen.  Die WDP-Dienst aktiviert und kommuniziert mit der App-Pakete im Manifest-Plug-in über den app Service beschrieben. Die app Service-Verbindung-Funktionen wie eine benannte Pipe mit dem WDP fungiert als des Clients über diese Verbindung verwendet werden soll, und die App-Plug-in als Server fungiert. Dieser Entwurf Sponsorship wird sichergestellt, dass lang andauernde Anforderungen durch das System Ressourcenverwaltungsrichtlinien unterbrochen werden nicht. Die Laufzeit WDP beginnt der Wartung von Anforderungen im Auftrag des Plug-Ins.  Inhaltsanforderungen werden automatisch abgewickelt, während der REST-API-Anforderungen an die App-Plug-ins registrierten Ereignishandler von RequestReceived gesendet werden. Plug-in-Lebensdauer wird durch den WDP-Dienst und der Prozess Gültigkeitsdauer-Manager (PLM) verwaltet. Weitere Informationen zum Verwalten von Plug-in-Zustand, wenn eine Hintergrundtask angehalten wird, finden Sie unter "Starten, fortgesetzt und Tasks im Hintergrund" im Artikel (bit.ly/2u0N7fO). Ein Job-Objekt wird sichergestellt, dass WDP Dienst Rundownanbieter abgeschlossen ist, Beenden alle ausgeführten WDP Sponsoren und ihre zugeordneten verpackt-Plug-ins.

Schreiben ein App-Plug-in

Erstellen das Projekt vor dem Erstellen Ihrer App-Plug-in, müssen Sie entscheiden, ob Ihre Web-anforderungshandlers ein Hintergrundtask ausgeführt werden kann, oder gibt an, ob er im Prozess einer Vordergrund-app ausgeführt werden muss. Vordergrund Ausführung ist erforderlich, wenn z. B. den Handler für den Zugriff auf interne Datenstrukturen für die app erforderlich. Diese Flexibilität bei der Ausführung wird durch die zugrunde liegenden "appservice" aktiviert, die für den Hintergrund oder den Vordergrund Vorgang konfiguriert werden können. Eine ausführlichere Erläuterung der AppServices, finden Sie in den Artikeln "Erstellen und Nutzen eines Anwendungsdiensts" (bit.ly/2uZsSfz), und "Konvertieren einer App Service zu ausführen in der gleichen Prozess als ihr Host-App" (bit.ly/ 2u0G8n1).

Ich sende in diesem Beispiel implementiert einen Handler für Vordergrund und Hintergrund Handler und veranschaulichen die Integration Ihrer statischen Inhalte und REST-APIs. Zunächst erstellen eine neue Projektmappe in Visual Studio mit der leere App (universelle Windows) C#-Projektvorlage. Name der Projektmappe MyPackagedPlugin und das Projekt "MyApp". Den Handler Vordergrund Hosten der Anwendung.  Wenn Sie aufgefordert werden, als Ziel mindestens des Erstellers Update SDK (15063), um sicherzustellen, dass die Verfügbarkeit der WDP-API verwenden. Fügen Sie anschließend eine Komponente-Laufzeitbibliothek zur Projektmappe mithilfe der Windows Runtime Komponente Visual C#-Vorlage ein. Geben Sie diesem Projekt MyComponent. Diese Bibliothek wird den Hintergrund-Handler gehostet. 

Um sicherzustellen, dass die Komponente in der app-Paket enthalten ist, fügen Sie im app-Projekt einen Verweis darauf hinzu. Klicken Sie im Projektmappen-Explorer erweitern Sie den Projektknoten der app, mit der rechten Maustaste den Knoten "Verweise", und wählen Sie Verweis hinzufügen. Klicken Sie im Dialogfeld "Verweis-Manager" Erweitern Sie den Knoten "Projekte", wählen Sie die Projektmappe, und überprüfen Sie das Projekt MyComponent.

Legen Sie bevor Sie fortfahren die Projektmappenplattform entsprechend der Architektur des Computers ein. Dies ist eine Voraussetzung für eine App-Plug-in, da WoW64 nicht unterstützt wird. Beachten Sie, dass in diesem Fall, ich bin mit dem lokalen Computer bereitstellen, aber die Empfehlung gilt auch, wenn auf einem sekundären Zielgerät bereitstellen.

Bearbeiten das Manifest da es eine Reihe von Manifesten Änderungen erforderlich sind, ich werde die Datei "Package.appxmanifest" direkt bearbeiten, anstatt mithilfe des Designers. Klicken Sie im Projektmappen-Explorer unter dem Knoten "app" mit der rechten Maustaste auf die Datei "Package.appxmanifest"-Knoten, und wählen Sie Code anzeigen, um den XML-Code zu bearbeiten.

Beginnen Sie durch Hinzufügen der uap4 und Rescap Namespacedeklarationen und Aliase, die werden für nachfolgende Elemente erforderlich:

<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">

Um das Paket während des Debuggens mehr erkennbar zu machen, werde ich den Paketnamen aus einer generierten GUID in einen aussagekräftigeren Namen ändern:

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

Ich werde fügen Sie der app-Erweiterungen erforderlich, für jeden gepackte-Plug-in-Handler auf das Element Package\applications\application\extensions entsprechend Abbildung 4

Abbildung 4-Hinzufügen von App-Erweiterungen

<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>

Jeder Handler erfordert zwei Erweiterungen. Die Erweiterung "appservice" bietet es sich um die Aktivierung Mechanismus und Kommunikation Kanal zwischen dem WDP-Dienst und das Hosten des Handlers der WDP-Laufzeit. Gemäß der Konvention verwendet AppServices ein reverse-Domäne-Namen-Schema zum Sicherstellen der Eindeutigkeit. Wenn Sie einen Hintergrund "appservice" zu implementieren, wird die EntryPoint-Attribut ist erforderlich und gibt an, an der Ausführung beginnt. Wenn ein Foreground "appservice" zu implementieren, wird die Ausführung mit der app OnBackgroundActivated Methode beginnt und die EntryPoint-Attribut fehlt.

Die DevicePortalProvider-Erweiterung bietet Konfigurationsdaten für die DevicePortalConnection, die den Handler hostet. Eine DevicePortalProvider stellt die Clientseite der Verbindung "appservice" URL-Handler für das DevicePortalConnection bereitzustellen. Das AppServiceName-Attribut muss mit dem Name-Attribut des Elements "appservice" (z. B. com.contoso.www.myapp) entsprechen. Das Element DevicePortalProvider möglicherweise eine ContentRoute angeben, statische Webinhalte zu verarbeiten; eine HandlerRoute für die Verteilung von Anforderungen an einen Handler für die REST-API; oder beides. ContentRoute und HandlerRoute muss eindeutig sein. Wenn entweder steht in Konflikt mit einer integrierten WDP Route oder eine zuvor registrierten gepackte-Plug-in Route weiterleiten, wird das plug-in nicht geladen, eine entsprechende diagnosemeldung darstellen. Darüber hinaus die relativer URL auf einen relativen Pfad unter dem Paket zuordnen muss ContentRoute-Installationsordner (z. B. \myapp\www). Weitere Informationen finden Sie unter den DevicePortalProvider Erweiterung-Spezifikationen (bit.ly/2u1aqG8).

Schließlich füge ich die Funktionen für meine App-Pakete erforderlich-Plug-in:

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

Die PrivateNetworkClientServer-Funktion können HTTP. SYS-Funktionalität in einer AppContainer. In dieser Demo werde ich das Paket direkt in Visual Studio auf dem lokalen Computer für die Ausführung bereitstellen.  Allerdings zum Integrieren Ihrer app in den Speicher auch müssen Sie die Funktion für DevicePortalProvider abrufen, wofür die Microsoft-Partner beschränkt ist. Weitere Informationen finden Sie im Artikel "App-Funktionsdeklarationen" (bit.ly/2u7gHkt). Diese Funktionen sind mindestens erforderliche WDP Common Language Runtime eine gepackte Host-Plug-in. Das Plug-in Handlercode möglicherweise zusätzliche Funktionen, abhängig von den universellen Windows-Plattform-APIs, die ihn aufruft. 

Hinzufügen von statischen Inhalten weiter aus, für das plug-in eine Seite erstellen. Die Seite, und anderen statischen Inhalten, auf die es verweist, sollte in einem anwendungsrelativen Pfad, die Inhalt Route, die für das plug-in reserviert entspricht in diesem Fall /myapp/www platziert werden. Klicken Sie im Projektmappen-Explorer mit der rechten Maustaste auf den Projektknoten der app, und wählen Sie hinzufügen | Neuen Ordner. Benennen Sie den Ordner "MyApp". Mit der rechten Maustaste auf den Knoten neu hinzugefügten Ordner aus, und wählen Sie erneut hinzufügen | Neuer Ordner einen Unterordner erstellen, mit dem Namen Www. Drücken Sie STRG + N, und wählen Sie im Dialogfeld für neue Dateien, die allgemeinen | HTML-Seite-Vorlage. Speichern Sie diese Datei als "Index.HTML" in der Projektmappe MyPackagedPlugin\MyApp\myapp\www Pfad ein. Fügen Sie diese Datei dann in den Ordnerpfad Projekt, damit er als Paketinhalt eingeschlossen wurde. Mit der rechten Maustaste auf die neu hinzugefügte Datei "Index.HTML" Datei-Knoten, und wählen Sie Eigenschaften aus. Bestätigen Sie die Standardwerte für die Eigenschaft der Aktion zu erstellen: Inhalt, und Kopieren in Buildausgabeverzeichnis: Nicht kopieren.

Fügen Sie jetzt das Markup, das in angezeigten Abbildung 5 auf die neu erstellte Datei "Index.HTML". Auf dieser Seite zeigt mehrere Aufgaben aus. Zuerst, beachten Sie, dass integrierte WDP-Ressourcen, z. B. die Bibliotheken jquery.js und rest.js gepackte-Plug-ins, ebenfalls zur Verfügung. Dies ermöglicht eine gepackte-Plug-in domänenspezifische-Funktionalität mit integrierten WDP Funktionen kombinieren. Weitere Informationen finden Sie im Artikel "Gerät Portal-API-Referenz" (bit.ly/2uFTTFD). Zweitens, beachten Sie den Verweis auf das Plug-in REST-API-Aufrufe, /myapp/API/status der app und die Komponente /mycomponent/API/status aus.  Dies zeigt, wie ein Plug-in des statischen und dynamischen Inhalt problemlos kombiniert werden kann. 

Abbildung 5-Status-Seitenmarkup

<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>

Hinzufügen einer REST-API jetzt werde ich einen REST-API-Handler implementieren. Wie bereits erwähnt, hängt die Wahl des Einstiegspunkts gibt an, ob ein Hintergrund oder den Vordergrund "appservice" implementiert wird. Über ein geringfügiger Unterschied in wie die eingehende Verbindung der App Service abgerufen wird ist die Geräteverbindung-Portal-Implementierung für beide Szenarien identisch. Ich beginnen mit der app Vordergrund Handler.

Öffnen Sie die Quelldatei App.xaml.cs und fügen Sie die folgenden Namespaces, die für alle Ereignishandler erforderlich:

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

Innerhalb der Klassendefinition MyApp.App fügen ich einige Elemente um den Handler Zustand zu implementieren.  BackgroundTaskDeferral Beendigung des Hintergrundtasks orientiert sich, dass Hosts die Ausführung des ereignishandlers und DevicePortalConnection implementiert, die Verbindung mit dem WDP-Dienst selbst.

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

Als Nächstes überschreiben den Hintergrund-Aktivierung-Handler für die app, instanziieren ein DevicePortalConnection und seine Ereignisse abonnieren, entsprechend Abbildung 6.

Abbildung 6 implementieren die 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;
}

Für diesen Handler ich einfach lernen für Anforderungen an den URI /myapp/API/status, und beantworten Sie mit einer JSON-Struktur entsprechend Abbildung 7. Eine komplexere Implementierung konnte mehrere Routen zu unterstützen, ruft von Beiträgen unterschieden, überprüfen die URI-Parameter und usw..

Abbildung 7 die Anforderung behandelnden

// 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;
  }
}

Schließlich ich schließen die DevicePortalConnection, mit dessen Closed-Ereignis direkt oder indirekt nach Abbruch des Vorgangs im Hintergrund behandeln, wie in gezeigt Abbildung 8.

Abbildung 8 die DevicePortalConnection schließen

// 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();
}

Implementierung der Handler für das Komponentenprojekt Hintergrund ist nahezu identisch mit dem Vordergrund-Beispiel. Öffnen Sie die Datei "Class1.cs" und fügen Sie die erforderlichen Namespaces, wie zuvor. Ersetzen Sie die Definition der generierten Klasse innerhalb des komponentennamespace mit einer Klasse IBackgroundTask und seine erforderliche "Run"-Methode implementieren: 

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

Die "Run"-Methode akzeptiert einen Parameterwert IBackgroundTaskInstance direkt. Beachten Sie, dass die Vordergrund-Handler dieser Wert aus der TaskInstance Member des Parameters BackgroundActivatedEventArgs der OnBackgroundActivated abgerufen. Abgesehen von dieser Unterschied beim Abrufen der TaskInstance ist die Implementierung für beide Handler identisch. Kopieren Sie die verbleibenden Implementierung aus den Vordergrund Handler App.xaml.cs.

Testen einer App-Plug-in

Bereitstellen von-Plug-In für das plug-in testen, müssen Sie zuerst bereitstellen, entweder über Visual Studio F5-Bereitstellung oder über lose AppX-Dateien (generiert wurde, über die Visual Studio-Projekt | Store | Erstellen Sie App-Pakete). Wir verwenden das Erstere. Mit der rechten Maustaste auf den Projektknoten "MyApp", und wählen Sie Eigenschaften aus. Klicken Sie im Eigenschaftenblatt Projekts, wählen Sie die Registerkarte "Debuggen", und aktivieren Sie die stimmen nicht starten Sie das Kontrollkästchen.

Ich schlage vor Festlegen eines Haltepunkts im Ereignishandler RequestReceived und möglicherweise in Ihrem-Plug-ins Einstiegspunkt – Ihre Ereignishandler BackgroundActivated oder die "Run"-Methode außer Kraft setzen. Hierdurch wird bestätigt, dass das plug-in ordnungsgemäß konfiguriert ist und erfolgreich aktivieren beim Testen im nächsten Abschnitt wird.  Jetzt, drücken Sie F5 zum Bereitstellen und Debuggen der app ein.

Ausgeführte WDP im Debug-Modus nach der Bereitstellung des Pakets, WDP muss neu gestartet werden, um es zu erkennen. (Für den Fall, dass die zuvor erwähnte WDP-Einführung übersprungen wird, müssen Sie möglicherweise auch das Entwicklermodus-Paket jetzt zu installieren, um sicherzustellen, dass WDP verfügbar ist). Dies kann geschehen, indem Sie das Kontrollkästchen aktivieren-Geräteportal von Update und Sicherheit der Einstellungs-app umschalten | Für Entwickler-Seite. Allerdings werde ich stattdessen die WDP-Dienst als eine Konsolen-app im Debugmodus ausgeführt werden. Dies ermöglicht, dass ich WDP Ablaufverfolgungsausgabe, finden bei der Problembehandlung von App-Plug-in-Konfiguration und ausführungsprobleme derer. Der Dienst WDP ist so konfiguriert, dass unter dem Systemkonto ausgeführt, und dies ist auch erforderlich, wenn WDP im Debugmodus ausgeführt. Das PsExec-Hilfsprogramm verfügbar als Teil der PsTools-Suite (bit.ly/2tXiDf4), hilft nachholen.

Erstellen Sie zunächst eine Systemkonsole PsExec aus in der Administratorkonsole ausgeführt wird:

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

Dieser Befehl startet einen zweiten Konsolenfenster im Systemkontext Konto ausgeführt. In der Regel wird dieses Fenster verwendet die legacy-Konsole, und neue Konsolenfunktionen, z. B. Zeilenumbruch auf zum Ändern der Größe, Erweiterungen der Text-Auswahl und Zwischenablage Tastenkombinationen, sind nicht verfügbar. Wenn diese Funktionen aktiviert, wenn er als SYSTEM ausgeführt werden sollen, speichern Sie Folgendes in einer Skriptdatei für die Registrierung (z. B. EnableNewConsoleForSystem.reg), und führen Sie sie aus:

Windows Registry Editor Version 5.00

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

Führen Sie in der Systemkonsole WDP im Debugmodus befindet, Aktivieren von unverschlüsselten und einem verschlüsselten Anforderungen ein: 

> Webmanagement-debug - Clearandssl

Sollte eine Ausgabe ähnlich wie in Abbildung 9.  Um WDP sicher im Debugmodus befinden, zu beenden, drücken Sie einfach STRG + C. Dies wird der Systemkonsole verwalten, damit Sie auf die Plug-in-Entwicklungen durchlaufen können. 

Windows-Device-Portal im Debug-Modus

Abbildung 9 Windows Device-Portal im Debug-Modus

Beachten Sie, dass die Ausgabe der Ablaufverfolgung mit verschiedenen Begriffe verwendet: Webmanagement, WebB und WDP. Diese Verlaufsgründen vorhanden sind, und verweisen auf die verschiedenen Subsysteme, aber die Unterschiede können ignoriert werden. Beachten Sie, dass im Debugmodus ausgeführt wird, eine andere Konfiguration ausführen als Dienst verwendet. Im Debugmodus befindet, ist beispielsweise standardmäßig Autorisierung standardmäßig deaktiviert. Dies vermeidet die Notwendigkeit, Anmeldeinformationen einzugeben und verhindert das automatische HTTPS Umleitung, vereinfachen die Tests in einem Browser oder das Befehlszeilen-Hilfsprogramm. Darüber hinaus wurden die Ports Werte 54321 und 54684 zugewiesen. In der Regel verwendet der desktop WDP Dienst Ports 50080 und 50443 (obwohl dies vorgenommen werden, zufälligen Ports dynamisch zugewiesen werden). Dies ermöglicht WDP im Debugmodus ausführen, ohne Konflikte mit den Produktionsmodus von WDP als Dienst ausgeführt wird. Allerdings kann es die Portnummern für URLs zu wechseln, beim Testen, je nach der Ausführung WDP irksome werden. Wenn dies der Fall ist, können Sie die Befehlszeilenoptionen - HttpPort und -HttpsPort, explizit die Portnummern Produktionsmodus entsprechend festgelegt. In diesem Fall müssen Sie sicherstellen, dass der WDP-Dienst deaktiviert ist, um Konflikte zu vermeiden. Um alle WDP Befehlszeilenoptionen anzuzeigen, geben Sie Folgendes ein:

> WebManagement.exe-?

Wie in der Ablaufverfolgungsausgabe angegeben wird, werden mehrere integrierte-Plug-ins als Teil des WDP startet automatisch geladen. WDP und Berichte, die die Ermittlung von der bereitgestellten verpackt-Plug-in mit "gefunden 2 Pakete" (genauer gesagt, ein Paket mit zwei Anbieter). Der erste Anbieter beschreibt den Vordergrund-Handler und bestätigt die statische ContentRoute-URL-Reservierung und dem entsprechenden Paket-Dateipfad und den REST HandlerRoute zugeordnet. An diesem Punkt WDP verfügt über eine Warteschlange bei Bedarf HTTP-Anforderung, für den Dienst mit diesen Routen erstellt und wartet auf Anforderungen. Der zweite Datenanbieter beschreibt den Hintergrund-Handler, der nur eine REST-HandlerRoute angibt. Es ist, für Unternehmen bereit.

Ausführen des Plug-Ins ich wird empfohlen, entwickeln und testen das plug-in mit ausgezeichnete Befehlszeilen-Hilfsprogramm, die weiter oben erwähnt, curl. Für Szenarien mit einfacher ein Browser ist ausreichend, aber Curl bietet eine präzisere Kontrolle über die Header, Authentifizierung und So weiter. Dies erleichtert das zu verwendende WDP-Verschlüsselung, Authentifizierung und Optionen von CSRF-Schutz aktiviert sind. In solchen Fällen können die Curl "– verbose" Option ist auch nützlich für die Problembehandlung.

Abbildung 10 veranschaulicht den Vordergrund Handler Ressourcen anfordern: den Status REST-API und die Webseite. 

Testen mit Curl

Abbildung 10 Tests mit Curl

Abbildung 11 gezeigt, die mit dem Browser, um die app-Statusseite anzufordern, wiederum veranschaulichen den eingebetteten REST-API aufruft.

Mit dem Browser testen

Abbildung 11, die mit dem Browser testen

Wenn alle Anforderungen an Ihre-Plug-ins Routen vorgenommen werden, sollten den in Ihr Ausgangspunkt festgelegten im Debugger Haltepunkt. Und für REST-API-Anforderungen insbesondere der Breakpoint im Ereignishandler RequestReceived sollten erreicht. Sie sollten auch sehen, Bestätigung in die Diagnose WDP auszugeben, die App-Plug-in wurde aktiviert.

Problembehandlung für sie ist erwähnenswerte nur einige der üblichen Fehler, die korrekte Ausführung einen Handler zu verhindern:

  • Konflikte, wie z. B. "appservice" Name "oder" Eintrag Point Manifest
  • Wenn Sie einen Projektverweis auf die app im Hintergrund Handler Komponente hinzufügen
  • Bereitstellen einer Architektur nicht übereinstimmenden zwischen dem Paket und dem Dienst
  • Implementieren IBackgroundTask im app-Projekt und nicht als ein Windows-Runtime-Komponente

Wenn im Debugmodus ausgeführt wird, kann WDP spezifischen diagnosemeldungen für diese Fehler möglichst ermöglichen. Nach drei Versuche, ein plug-in zu aktivieren, fehlgeschlagen, deaktiviert WDP das plug-in für die jeweilige Sitzung wie angegeben mit der Diagnose:

WDP Packaged Plugin: Disabling request queue after 3 failed attempts

Nach Korrekturen an Ihrem Paketmanifest oder Code vorgenommen werden, ist es normalerweise erforderlich, WDP, damit der deaktivierten Zähler zurückgesetzt und konfigurationsänderungen des Pakets neu einlesen neu zu starten.

Zusammenfassung

Die Windows-Geräte-Portal-API bietet einen sichere, einfachen Mechanismus zum Erweitern von Diagnosefunktionen für Ihre Windows Store-app mit App-Plug-ins. Zukünftige Erweiterungen auf diese API werden Aktivieren der Integration der App-Plug-ins in der UI WDP einführen von REST-APIs für die Installation und Steuern der App-Plug-ins und erweitern Sie die Anwendungen möglich, dass App-Plug-ins.


Scott Jones im Team Anwendungsplattform und Tools für Microsoft als Softwareentwickler funktioniert.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels:  Hirsch Langohr


Diesen Artikel im MSDN Magazine-Forum diskutieren