Ottobre 2017
Volume 32 Numero 10
Il presente articolo è stato tradotto automaticamente.
C# - Scrivi un plug-in Windows Device Portal in pacchetto
Da Jones Scott
Tra fanfare della versione di Windows 10, una funzionalità apportate una debutto non interattiva: Portale di dispositivi di Windows (WDP). WDP è un sistema di diagnostica basata sul Web integrato di Windows 10. Dopo la distribuzione progressiva, WDP è ora disponibile in HoloLens IoT, dispositivi mobili, Desktop e Xbox. Sono previsti da includere nel nuovo edizioni di Windows non appena vengono rilasciate. Fatta eccezione per Windows Desktop, WDP è immediatamente disponibile all'esterno della casella. Sul Desktop, WDP è disponibile con il download e installazione del pacchetto facoltativo modalità sviluppatore di Windows Update. In questo articolo, verrà spiegato come utilizzare l'API WDP per implementare un WDP incluso nel pacchetto del plug-in per estendere l'app di Windows Store con l'API REST personalizzate. Mentre lo stato attivo di questo articolo è sul Desktop di Windows, i concetti e tecniche si applicano anche ad altre edizioni di Windows.
Per creare ed eseguire un pacchetto di WDP plug-in, è necessario aggiornare il sistema almeno al 10 creatori in Windows Update (10.0.15063.0) e installare Windows 10 SDK corrispondente (bit.ly/2tx5Bnk). Per istruzioni dettagliate, vedere l'articolo, "Aggiornamento di strumenti per Windows 10 creatori Update" (bit.ly/2tx3FeD). Potrebbe essere necessario riavviare il computer rilevare e supportano il nuovo SDK; Visual Studio in caso contrario progetti caricamento potrebbero non riuscire.
Se non si ha familiarità con WDP, si consiglia di leggere l'articolo, "Cenni preliminari sul portale dispositivo di Windows" (bit.ly/2uG9rco). Questo verrà fornita un'introduzione alle funzionalità di WDP e assicura anche che è stata installata prima di procedere con la scrittura in un pacchetto del plug-in.
In breve, è necessario scaricare e installare il pacchetto opzionale contenuto modalità sviluppatore. Dall'app impostazioni (premere Windows + I), individuare l'aggiornamento e sicurezza | Per gli sviluppatori pagina e selezionare la modalità sviluppatore pulsante di opzione. Una volta completato l'installazione del pacchetto in modalità sviluppatore, selezionare la casella di controllo Abilita portale dispositivo, impostare credenziali come desiderato e passare all'URL specificato per verificare la funzionalità. Dopo l'accettazione di WDP di certificato autofirmato e immissione delle credenziali, il browser dovrebbe visualizzare l'interfaccia utente Web WDP, come illustrato nella figura 1.
.jpg "Interfaccia utente Web del portale dispositivo Windows")
Figura 1 dispositivo del portale Web di Windows dell'interfaccia utente
Architettura WDP
Gli strumenti presentati nell'UI WDP in figura 1 vengono implementate con i controlli JavaScript che comunicano con le API REST ospitato nel servizio WDP. Come le API REST, queste richieste Web generalizzate e senza state sono applicabili in più contesti di semplicemente la UI WDP. Ad esempio, un'API REST WDP potrebbe essere chiamata da uno script di Windows PowerShell o un agente utente personalizzata. Il WindowsDevicePortalWrapper (bit.ly/2tx2NXF) progetto open source offre una libreria per lo sviluppo di agenti utente WDP personalizzati in c#. In questo articolo, utilizzerà il browser e curl l'utilità della riga di comando disponibile (curl.haxx.se) per provare l'API REST personalizzate.
WDP è stato progettato tenendo in considerazione l'estensibilità. Ad esempio, WDP personalizzato per ogni edizione di Windows tramite plug-in predefiniti. Con l'aggiornamento di creatori di Windows 10, è ora possibile di terze parti estendere WDP mediante la creazione di plug-nel pacchetto. In un pacchetto del plug-in fornisce endpoint REST personalizzati, con un facoltativo basato sul Web dell'interfaccia utente, implementazione e la distribuzione in un'app di Windows Store. Figura 2 viene illustrato come funziona il sistema.
.jpg "Architettura del portale di dispositivo Windows")
Figura 2 architettura di portale dispositivo Windows
Reader familiarità con le caratteristiche interne di verrà IIS Microsoft riconoscono la progettazione di WDP. Come con IIS, WDP si basa l'API Server HTTP (anche detto HTTP. SYS), divisione responsabilità tra i ruoli di lavoro di HTTP e HTTP Controller. Il servizio WDP implementa il controller in esecuzione con l'account sistema locale. Ogni WDP compresso implementa plug-in un thread di lavoro in esecuzione all'interno della sandbox di AppContainer nel contesto di sicurezza dell'utente.
È possibile ospitare un server Web da zero all'interno di un'app di store, Usa l'API Server HTTP. Tuttavia, che implementa un WDP compresso offerte plug-in diversi vantaggi. WDP offre servizi di crittografia, autenticazione e sicurezza per tutti i contenuti e le API REST, comprese quelle dei plug-nel pacchetto. Ciò include la protezione da richieste intersito false e intersito WebSocket attacchi. Inoltre, WDP gestisce la durata di ogni pacchetto plug-in, che può essere eseguita da un'app di primo piano dell'interfaccia utente visibile o come attività in background. In breve, è più semplice e sicuro implementare le API REST con un pacchetto del plug-in. Il diagramma di sequenza figura 3 illustra il flusso di esecuzione per un pacchetto di plug-in.
.jpg "Attivazione e l'esecuzione di un pacchetto di plug-in")
Figura 3 attivazione e l'esecuzione di un pacchetto di plug-in
Nel pacchetto app manifesto, ogni plug-in identifica con un servizio di app associata e l'estensione dell'app windows.devicePortalProvider e dichiara la route (URL) di interesse. Un plug-in può registrare una route di contenuto, una route di API REST o entrambi. Al momento dell'installazione del pacchetto, i dati del manifesto sono registrati con il sistema.
All'avvio, il servizio WDP analizza il sistema per WDP incluso nel pacchetto plug-in registrati, identificato con l'estensione dell'app windows.devicePortalProvider. Per ogni plug-in individuazione, il servizio WDP legge il manifesto del pacchetto di informazioni sulle route. Il set delle route richieste per il pacchetto plug-in, detto URLGroup, è registrato con HTTP. SYS per creare una coda di richieste HTTP su richiesta. Il servizio WDP quindi monitora ogni coda di richieste di plug-nel pacchetto per le richieste in ingresso.
Alla prima richiesta di route per un plug-in, il servizio WDP avvia sponsor WDP nel contesto di sicurezza dell'utente. Lo sponsor WDP a sua volta attiva il pacchetto del plug-in, il trasferimento di coda di richieste HTTP per il plug-in. Il servizio WDP attiva e comunica con il pacchetto del plug-in tramite il servizio app descritto nel manifesto. Le funzioni di connessione del servizio app come una named pipe, con lo sponsor WDP funge da client di connessione e il pacchetto che agisce come server di plug-in. Questa progettazione sponsorizzazione assicura che le richieste a esecuzione prolungata non venga interrotta dai criteri di gestione risorse di sistema. Il runtime WDP inizia quindi soddisfare le richieste per conto del plug-in. Le richieste di contenuto vengono gestite automaticamente, mentre le richieste API REST vengono inviate per registrati RequestReceived gestore il pacchetto del plug-in. Plug-in durata è gestita dal servizio WDP e il processo di gestione del ciclo di vita. Per ulteriori informazioni sulla gestione dello stato del plug-in quando un'attività in background viene sospeso, vedere l'articolo "Avvio, ripresa dell'esecuzione e le attività in Background" (bit.ly/2u0N7fO). Un oggetto processo ulteriormente garantisce che rundown servizio WDP è stata completata, terminare qualsiasi WDP esecuzione pacchetto sponsor e i relativi plug-in.
Scrittura in un pacchetto del plug-in
Creare il progetto prima di creare il pacchetto del plug-in, è necessario decidere se eseguire il gestore di richieste Web come attività in background o se deve essere in esecuzione in corso di un'app in primo piano. Esecuzione di primo piano è necessario se, ad esempio, il gestore richiede l'accesso alle strutture dati interne dell'app. Questa flessibilità nell'esecuzione è abilitata per il servizio App sottostante, che può essere configurato per l'operazione in background o in primo piano. Per una descrizione più dettagliata di AppServices, consultare gli articoli, "Creazione e utilizzo di un servizio di App" (bit.ly/2uZsSfz) e "Convertire un'App del servizio per eseguire nel stesso processo come relativo Host App" (bit.ly/ 2u0G8n1).
In questo esempio verrà implementare un gestore di primo piano e un gestore di sfondo e dimostrare l'integrazione del contenuto statico e le API REST. Iniziare creando una nuova soluzione in Visual Studio con il modello di progetto applicazione vuota (Windows universale) in c#. Nome della soluzione MyPackagedPlugin e il progetto MyApp. L'app verrà ospitato il gestore di primo piano. Quando richiesto, fare riferimento ad almeno aggiornamento SDK del creatore (15063), per garantire la disponibilità dell'API WDP. Aggiungere quindi una libreria di componenti di runtime per la soluzione, utilizzando il modello di Windows Runtime componente Visual c#. Denominare il progetto di componente. Questa raccolta verrà ospitato il gestore di sfondo.
Per garantire che il componente è incluso nel pacchetto dell'app, aggiungere un riferimento a esso nel progetto dell'app. In Esplora soluzioni, espandere il nodo di progetto di app, fare doppio clic su nodo Riferimenti e scegliere Aggiungi riferimento. Nella finestra di dialogo Gestione riferimenti espandere il nodo dei progetti, selezionare una soluzione e archiviare il progetto di componente.
Prima di proseguire, impostare la piattaforma della soluzione per la corrispondenza dell'architettura del computer. Questo è un requisito per un pacchetto del plug-in, come WoW64 non è supportato. Si noti che in questo caso, viene distribuito al computer locale, ma l'avviso si applica anche quando la distribuzione in un dispositivo di destinazione secondario.
Modifica il manifesto perché vi sono necessari un numero di modifiche al manifesti, modificherà il file package. appxmanifest direttamente, anziché utilizzare la finestra di progettazione. In Esplora soluzioni, sotto il nodo di app, fare clic sul nodo del file package. appxmanifest e scegliere Visualizza codice per modificare il file XML.
Inizia ad aggiungere il uap4 e rescap dichiarazioni di spazi dei nomi e gli alias che saranno necessari per gli elementi successivi:
<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">
Per rendere più facilmente individuabili durante il debug del pacchetto, modificherà il nome del pacchetto da un GUID generato in un nome significativo:
<Identity Name="MyPackagedPlugin" Publisher="CN=msdn" Version="1.0.0.0" />
Successivamente, aggiungerà le estensioni per app richieste per ogni gestore plug-in pacchetto e l'elemento package\applications\application\extensions, come illustrato nella figura 4.
Figura 4 aggiunta di estensioni dell'App
<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>
Ogni gestore richiede due estensioni. L'estensione del servizio App offre il canale di comunicazione e meccanismo di attivazione tra il servizio WDP e il runtime WDP che ospita il gestore. Per convenzione, AppServices utilizza una combinazione di nome di dominio inverso per garantire l'univocità. Implementazione di uno sfondo AppService, l'attributo del punto di ingresso è obbligatorio e specifica in cui inizia l'esecuzione. Se l'implementazione di un servizio app di primo piano, l'esecuzione inizia con metodo OnBackgroundActivated dell'app e il punto di ingresso attributo viene omesso.
L'estensione DevicePortalProvider fornisce dati di configurazione per DevicePortalConnection che ospita il gestore. Un DevicePortalProvider rappresenta il lato client della connessione di servizio App, fornendo i gestori di URL per il DevicePortalConnection. L'attributo AppServiceName deve corrispondere con l'attributo Name dell'elemento di servizio App (ad esempio, com.contoso.www.myapp). L'elemento DevicePortalProvider può specificare un ContentRoute per la gestione di contenuti Web statici; un HandlerRoute per l'invio di richieste per un gestore di API REST. o entrambi. ContentRoute sia HandlerRoute deve essere univoco. Se i conflitti di indirizzare una route WDP predefinita o con una route di plug-in package registrata in precedenza, il plug-in non riuscirà da caricare, presentazione di un messaggio di diagnostica appropriato. Inoltre, il relativo URL deve eseguire il mapping a un percorso relativo del pacchetto di ContentRoute installare cartella (ad esempio \myapp\www). Per ulteriori informazioni, vedere la specifica di estensione DevicePortalProvider (bit.ly/2u1aqG8).
Infine, aggiungeranno le funzionalità necessarie per il pacchetto del plug-in:
<Capabilities>
<Capability Name="privateNetworkClientServer" />
<rescap:Capability Name="devicePortalProvider" />
</Capabilities>
La funzionalità privateNetworkClientServer consente HTTP. Funzionalità SYS in un AppContainer. In questo video dimostrativo, dovrà essere distribuito il pacchetto direttamente da Visual Studio nel computer locale per l'esecuzione. Tuttavia, per caricare app nello Store, è anche necessario ottenere la funzionalità devicePortalProvider, che è limitata ai partner Microsoft. Per ulteriori informazioni, consultare l'articolo "Dichiarazioni di funzionalità delle App" (bit.ly/2u7gHkt). Queste funzionalità sono la minima necessaria per il runtime WDP all'host in un pacchetto del plug-in. Gestore il codice del plug-in potrebbe richiedere ulteriori funzionalità, a seconda di API della piattaforma Windows Universal chiama.
Aggiunta di contenuto statico successiva, è possibile crearne una pagina di stato per il plug-in. La pagina e altri contenuti statici che cui fa riferimento, deve essere inseriti in un percorso relativo dell'applicazione corrispondente alla route del contenuto riservata per il plug-in, in questo caso, /myapp/www. In Esplora soluzioni fare doppio clic sul nodo del progetto di app, quindi scegliere Aggiungi | Nuova cartella. Nome di cartella di myapp. Fare clic sul nodo cartella appena aggiunta e selezionare di nuovo Aggiungi | Nuova cartella per creare una sottocartella denominata www. Premere Ctrl + N e nella finestra di dialogo Nuovo File, selezionare Generale | Modello di pagina HTML. Salvare questo file come index.html nel percorso MyPackagedPlugin\MyApp\myapp\www della soluzione. Aggiungere quindi questo file per il percorso della cartella di progetto, in modo che è incluso come contenuto del pacchetto. Fare clic sul nodo del file index.html appena aggiunto e scegliere Proprietà. Verificare i valori predefiniti delle proprietà dell'azione di compilazione: Il contenuto e copiare nella Directory di Output: Non copiare.
A questo punto aggiungere il markup figura 5 per il index.html appena creato. Questa pagina illustra diversi aspetti. In primo luogo, si noti che le risorse WDP predefinite, ad esempio le librerie jquery.js e rest.js, disponibile nel pacchetto plug-in, nonché. In questo modo, in un pacchetto del plug-in per combinare funzionalità specifiche del dominio con funzionalità WDP incorporata. Per ulteriori informazioni, consultare l'articolo "Riferimento all'API di dispositivo portale" (bit.ly/2uFTTFD). In secondo luogo, si noti il riferimento chiamate API REST, /myapp/API/status dell'app sia /mycomponent/API/status del componente del plug-in. Viene illustrato come contenuto statico e dinamico di un plug-in può essere combinato con facilità.
Figura 5 Markup della pagina stato
<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: <span id="app_status" style="color:green"></span>
<br/>
Component Status: <span id="comp_status" style="color:green"></span>
</div>
</body>
</html>
Aggiunta in corso di un'API REST si implementerà un gestore di API REST. Come accennato in precedenza, scelta del punto di ingresso varia a seconda se uno sfondo o primo piano di servizio App in fase di implementazione. Oltre una differenza minore in modalità aver stabilito la connessione di servizio App in ingresso, l'implementazione di connessione del dispositivo portale è identico per entrambi gli scenari. Inizierà con il gestore di primo piano dell'app.
Aprire il file di origine App.xaml.cs e aggiungere gli spazi dei nomi seguenti, necessari per ogni gestore:
using Windows.ApplicationModel.AppService;
using Windows.ApplicationModel.Background;
using Windows.System.Diagnostics.DevicePortal;
using Windows.Web.Http;
using Windows.Web.Http.Headers;
All'interno della definizione di classe MyApp.App, aggiungerò alcuni membri per implementare lo stato del gestore. BackgroundTaskDeferral rinvia il completamento dell'attività in background che l'esecuzione del gestore dell'host e DevicePortalConnection implementa la connessione al servizio WDP stesso.
sealed partial class App : Application
{
private BackgroundTaskDeferral taskDeferral;
private DevicePortalConnection devicePortalConnection;
private static Uri statusUri = new Uri("/myapp/API/status", UriKind.Relative);
Successivamente, eseguire l'override del gestore di attivazione in background per l'app, creare un'istanza di un DevicePortalConnection e sottoscrivere gli eventi, come illustrato nella figura 6.
Figura 6 implementazione il 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;
}
Per questo gestore, sarà sufficiente cercare richieste per l'URI /myapp/API/status e rispondere con una struttura JSON, come illustrato nella figura 7. Un'implementazione più complessa può supportare più route, distinguere tra get e post, controllare i parametri URI e così via.
Figura 7 gestisce la richiesta
// 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;
}
}
Infine, è possibile gestire la chiusura della finestra di DevicePortalConnection, direttamente con il relativo evento chiuso o indirettamente dall'annullamento dell'attività in background, come illustrato nella figura 8.
Figura 8, la chiusura di 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();
}
Implementazione del gestore di sfondo del progetto di componente è quasi identico all'esempio di primo piano. Aprire il file di origine Class1. cs e aggiungere gli spazi dei nomi necessari, come in precedenza. All'interno di nomi del componente, sostituire la definizione di classe generata con una classe che implementa IBackgroundTask e il relativo metodo di esecuzione richiesto:
public sealed class MyBackgroundHandler : IBackgroundTask
{
public void Run(IBackgroundTaskInstance taskInstance)
{
// Implement as for foreground handler's OnBackgroundActivated...
}
}
Il metodo Run accetta un valore del parametro IBackgroundTaskInstance direttamente. Tenere presente che il gestore di primo piano ottenuta questo valore del membro TaskInstance del parametro BackgroundActivatedEventArgs di OnBackgroundActivated. A parte questa differenza di ottenere il taskInstance, l'implementazione è identico per entrambi i gestori. Copiare l'implementazione rimanente dal file App.xaml.cs del gestore in primo piano.
Test in un pacchetto del plug-in
Distribuzione di plug-in per testare il plug-in, è necessario innanzitutto distribuire, tramite la distribuzione di Visual Studio F5 o tramite i file con estensione AppX separati (generato tramite il progetto di Visual Studio | Archivio | Creare menu pacchetti dell'applicazione). Consente di usare il precedente. Pulsante destro del mouse sul nodo del progetto MyApp e selezionare proprietà. Nella finestra delle proprietà di progetto, selezionare la scheda Debug e quindi abilitare i non non avviare la casella di controllo.
È consigliabile impostare un punto di interruzione nel gestore dell'evento RequestReceived ed eventualmente punto di ingresso del plug-in, il metodo Run eseguire l'override o nel gestore dell'evento BackgroundActivated. Si verificherà che il plug-in sia configurato correttamente e attivazione correttamente durante il test nella sezione successiva. A questo punto, premere F5 per distribuire ed eseguire il debug dell'app.
WDP in esecuzione nel Debug in modalità dopo la distribuzione del pacchetto, WDP deve essere riavviato per individuarlo. (Nel caso in cui non si è eseguito l'introduzione di WDP indicato in precedenza, si potrebbe essere anche necessario installare il pacchetto di modalità sviluppatore ora per garantire che la disponibilità WDP). Questa operazione può essere eseguita selezionando la casella di controllo Abilita portale dispositivo dell'app impostazioni aggiornamento e sicurezza | Per la pagina di sviluppatori. Tuttavia, verrà invece di eseguire il servizio di WDP nella modalità di debug di un'applicazione console. In questo modo sia possibile vedere l'output di traccia WDP sarà utile quando la risoluzione dei problemi di configurazione del plug-in pacchetto e problemi di esecuzione. Il servizio WDP è configurato per l'esecuzione con l'account SYSTEM, e questo è necessario anche quando si esegue WDP in modalità di debug. L'utilità di PsExec, disponibile come parte della famiglia di prodotti PsTools (bit.ly/2tXiDf4), consente di eseguire questa operazione.
Creare innanzitutto una console di sistema, che esegue PsExec da una console di amministrazione:
> psexec -d -i -s -accepteula cmd /k title SYSTEM Console - Careful!
Questo comando verrà avviata una seconda finestra della console in esecuzione nel contesto dell'account di sistema. In genere, tale finestra utilizza la console legacy e nuove funzionalità di console, ad esempio testo a capo automatico sul ridimensionamento, i miglioramenti di selezione di testo e i collegamenti negli Appunti, non sono disponibili. Se si desidera abilitare queste funzionalità quando viene eseguito come sistema, salvare il codice seguente in un file di script del Registro di sistema (ad esempio, EnableNewConsoleForSystem.reg) ed eseguirlo:
Windows Registry Editor Version 5.00
[HKEY_USERS\.DEFAULT\Console]
"ForceV2"=dword:00000001
Nella console di sistema, eseguire WDP in modalità debug, abilitare le richieste sia chiara e crittografate:
> webmanagement -debug -clearandssl
Verrà visualizzato un output simile a quella di figura 9. Per terminare in modo sicuro WDP in modalità debug, premere Ctrl + C. Pertanto è possibile eseguire l'iterazione sullo sviluppo di plug-in gruppo manterrà la console di sistema.
.jpg "Portale di dispositivo Windows in modalità di Debug")
Figura 9 portale di dispositivo Windows in modalità di Debug
Si noti che l'output di traccia utilizza diversi termini: webmanagement, WebB e WDP. Questi per motivi storici esistono e fare riferimento a sottosistemi diversi, ma è possono ignorare le differenze. Si noti inoltre che l'esecuzione in modalità di debug utilizza una configurazione diversa dall'esecuzione come servizio. In modalità debug, ad esempio, autorizzazione predefinita è disabilitata per impostazione predefinita. Ciò evita la necessità di immettere le credenziali e impedisce HTTPS automatico il reindirizzamento, semplificando di test da un browser o l'utilità della riga di comando. Inoltre, le porte sono state assegnate valori 54321 e 54684. In genere, il servizio WDP desktop Usa le porte 50080 e 50443 (sebbene se questi sono stati eseguiti, porte casuali saranno assegnate in modo dinamico). In tal modo WDP viene eseguita in modalità di debug senza interferire con la modalità di produzione di WDP in esecuzione come servizio. Tuttavia, possono diventare fastidiosi presenti passare numeri di porta su URL durante il test, in base alla modalità WDP di esecuzione. In questo caso, è possibile utilizzare le opzioni della riga di comando - numero della porta HTTP e - httpsPort impostare in modo esplicito i numeri di porta per la corrispondenza delle modalità di produzione. In questo caso, è necessario garantire che il servizio WDP è disattivato per evitare conflitti. Per visualizzare tutte le opzioni della riga di comando WDP, digitare:
> WebManagement.exe-?
Come indicato nell'output di traccia, come parte di avvio WDP vengono caricati automaticamente plug-in predefiniti diversi. WDP tutti i report, l'individuazione di distribuito in un pacchetto del plug-in con "trovato 2 pacchetti" (più precisamente, un pacchetto con due provider). Il primo provider descrive il gestore di primo piano e conferma prenotazione dell'URL ContentRoute statico e corrispondente mappato al percorso di file del pacchetto e HandlerRoute REST. A questo punto, WDP ha creato una coda di richieste HTTP su richiesta per le route del servizio e le richieste in attesa. Il secondo provider descrive il gestore di background, che specifica solo un HandlerRoute REST. È pronto per le aziende.
L'esecuzione del plug-in consigliabile lo sviluppo e test del plug-in con l'utilità della riga di comando eccellente che già indicato in precedenza, curl. Per gli scenari più semplici, è sufficiente un browser, ma curl mette a disposizione un controllo accurato delle intestazioni, l'autenticazione e così via. Questo rende più facile da utilizzare quando le opzioni di protezione CSRF, l'autenticazione e crittografia WDP sono abilitate. In questi casi, il curl "-verbose" opzione è utile anche per la risoluzione dei problemi.
Figura 10 illustra la richiesta di risorse del gestore in primo piano: stato API REST e pagina Web.
.jpg "Test con Curl")
Figura 10 test con Curl
Figura 11 viene illustrato come utilizzare il browser per richiedere una pagina di stato dell'app, a sua volta dimostrazione incorporato chiamate API REST.
.jpg "Test con il Browser")
Figura 11 test con il Browser
Quando tutte le richieste vengono effettuate per route del plug-in, è necessario raggiungere il punto di interruzione impostati nel punto di ingresso nel debugger. E per le richieste API REST in particolare, il punto di interruzione nel gestore dell'evento RequestReceived necessario raggiungere. Verrà inoltre visualizzato l'output conferma nella diagnostica WDP il pacchetto è stato attivato plug-in.
Risoluzione dei problemi vale la pena notare alcuni errori comuni che impediscono la corretta esecuzione di un gestore:
- Mancata corrispondenza del manifesto, ad esempio AppService nome o punto di ingresso
- Tralascia aggiungere un riferimento di progetto di componente gestore di sfondo all'app
- Distribuzione con una mancata corrispondenza di architettura tra il pacchetto e il servizio
- Implementazione IBackgroundTask nel progetto dell'app, anziché come un componente Windows Runtime
Durante l'esecuzione in modalità di debug, WDP fornire messaggi di diagnostica specifici per questi errori, se possibile. Dopo tre tentativi non riusciti di attivare un plug-in, WDP disabiliterà il plug-in per la sessione come indicato con lo strumento di diagnostica:
WDP Packaged Plugin: Disabling request queue after 3 failed attempts
Dopo aver apportato le correzioni per il codice o un manifesto di pacchetto, in genere è necessario riavviare WDP, reimpostare il contatore disabilitato e l'analisi per le modifiche alla configurazione di pacchetto.
Conclusioni
L'API di portale dispositivo Windows offre un meccanismo semplice e sicuro per l'estensione delle funzionalità di diagnostica dell'applicazione Windows Store con plug-nel pacchetto. Miglioramenti futuri correlati a questa API verranno consentono l'integrazione di plug-in pacchetti all'interno di UI WDP, introducono le API REST per l'installazione e il controllo nel pacchetto di plug-in ed espandere le possibili per i plug-nel pacchetto di applicazioni.
Scott Jones funziona per Microsoft come software engineer del team di strumenti e piattaforma dell'applicazione.
Grazie per il seguente esperto tecnico di Microsoft per la revisione dell'articolo: Hirsch Giorgi
Viene illustrato in questo articolo nel forum di MSDN Magazine