In che modo un'app Metro in Windows 8 può comunicare con un'app desktop back-end sulla stessa macchina?

In una situazione in cui il frontend dell'interfaccia utente è stato creato utilizzando il nuovo stile di app Metro per Windows 8 e desideri che comunichi con un'applicazione .NET in esecuzione sul desktop sulla stessa macchina locale (ad esempio un'app di servizio Windows).

Quali forme di comunicazione interprocesso sono disponibili tra l'app metro e l'app desktop?

Grazie a Pavel Minaev del team di Visual Studio, che ha fornito alcune informazioni iniziali qui in un commento, citato:

Secondo Martyn Lovell, non esiste alcun meccanismo deliberato per questo, e alcuni che potrebbero essere usati per questo sono intenzionalmente limitati. Ad esempio, le pipe con nome non sono presenti né i file mappati in memoria. Ci sono socket (inclusi i socket del server), ma quando ti connetti a localhost, puoi connetterti solo alla stessa app. È possibile utilizzare file normali in una delle "cartelle note" condivise (Documenti, Immagini, ecc.), Ma si tratta di un trucco piuttosto rozzo che richiede il polling ed è visibile all'utente. - Pavel Minaev commentando questo problema

Quindi, fallendo gli approcci normali, stavo pensando di utilizzare i servizi web o di leggere / scrivere su un database per ottenere una qualche forma di comunicazione, che sembrano entrambe eccessive quando i processi sono in esecuzione sulla stessa macchina.

Quello che sto tentando qui ha senso? Vedo la necessità di un'app della metropolitana come interfaccia utente frontend per un servizio esistente in esecuzione sul desktop. O è meglio usare solo WPF per l'interfaccia utente frontend in esecuzione sul desktop (cioè un'app non metropolitana).

Sto portando il mio progetto esistente su Win8 in questo momento. Consiste nel servizio Windows e nell'applicazione del vassoio che comunicano tra loro tramite NamedPipes WCF. Come forse già saprai, Metro non supporta le pipe denominate. Ho finito per usare TcpBinding per la connessione full duplex.

Questo post descrive quali funzionalità sono supportate.

Un esempio del mio server WCF che il client Metro può utilizzare è qui .

Tieni inoltre presente che non puoi utilizzare WCF sincrono in Metro. Dovrai usare il wrapper basato su attività che è solo asincrono.

E grazie per la tua domanda. Sono stato un buon punto di partenza per me :)

C'erano una serie di domande come questa alla fine di una sessione // build / a cui ho partecipato. Aleš Holeček, il dirigente che ha tenuto una delle sessioni di film d'insieme, è uscito dal pubblico per occuparsene. Anche se non sei uno sviluppatore C ++, scarica quella sessione e guarda le domande e risposte http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C

Le app Metro non possono contare sull'installazione di app o servizi desktop sulla macchina. E le app desktop non possono contare sulle app Metro in esecuzione poiché possono essere sospese in qualsiasi momento. Devi iniziare a pensare in modo diverso. Ascolta Aleš su questo.

Tieni presente che con Windows 8.1 Update, la comunicazione tra le app di Windows Store e i componenti desktop scritti in C # per .NET 4.5+ è ora ufficialmente supportata per le applicazioni a caricamento laterale negli scenari Enterprise:

Componenti di Windows Runtime con brokeraggio per app di Windows Store caricate lateralmente

Per citare:

Riconoscendo che le funzioni e le regole aziendali critiche sono incorporate nelle risorse software esistenti e che le aziende hanno un'ampia varietà di scenari per i quali il nuovo stile di applicazione sarà altamente produttivo, l'aggiornamento di Windows 8.1 include una nuova funzionalità denominata Componenti di Windows Runtime con brokeraggio per il caricamento laterale applicazioni. Usiamo il termine IPC (comunicazione tra processi) per descrivere la capacità di eseguire asset software desktop esistenti in un unico processo (componente desktop) mentre si interagisce con questo codice in un'app di Windows Store. Questo è un modello familiare agli sviluppatori aziendali poiché le applicazioni di database e le applicazioni che utilizzano i servizi NT in Windows condividono un'architettura multi-processo simile.

Sebbene l'implementazione di questo approccio sia inizialmente un po 'complicata, consente una profonda integrazione tra Windows Store e componenti desktop. Tieni presente che per il momento non supererà la certificazione pubblica di Windows Store.

C'è un articolo su InfoQ su come creare app Metro poco accoppiate con gestori di protocollo. Questo è qualcosa che è stato supportato da Windows per molto tempo e si potrebbe prevedere che un'applicazione desktop si registri come gestore di protocollo e forse l'applicazione metro può comunicare attraverso questo meccanismo.

Non ho idea se sia possibile, ma potrebbe essere interessante dare un'occhiata.

Christophe Nasarre ha scritto sul blog di un modo piuttosto hacker per farlo utilizzando file locali. Il risultato è la comunicazione tra app desktop / app di Windows Store (indicata come DA / WSA nel blog), senza dover passare dall'interfaccia utente delle due app. Ha anche scritto sul blog di un'altra tecnica meno hacker che coinvolge gestori di protocollo.

Tieni presente che avere un WSA che comunica con un DA è esplicitamente vietato dai requisiti di certificazione dell'app del negozio

Le app di Windows Store non devono comunicare con applicazioni o servizi desktop locali tramite meccanismi locali, inclusi file e chiavi di registro.

... ma limita solo i "meccanismi locali". Quindi immagino che si possa costruire un servizio web per instradare le comunicazioni.

Se pensi di poter eseguire un'operazione manuale aggiuntiva di cmd, puoi provare:

X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;

CheckNetIsolation.exe è incluso nell'installazione di winRT, quindi non c'è niente di extra da installare.

L'ho provato: funziona, anche dopo l'aggiornamento del pacchetto.

Come mostrato su: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

Qui viene spiegato come scoprire il packageID della tua app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get- the-AppID-di-un-metro-style-app-

È possibile comunicare sulla stessa macchina dall'app Metro all'app desktop utilizzando il servizio locale. Ho implementato qualche tempo fa una semplice "prova di concetto", come bypassare la sandbox di WinRT utilizzando il servizio locale. Ha ancora bisogno di una sorta di "ingegneria sociale" o guida diretta per l'installazione del servizio, ma comunque è possibile.
Tuttavia, non sono sicuro delle regole di certificazione sulla comunicazione "servizio locale" quando si aggiunge tale app a Windows Store.

Campione qui

In base alla progettazione, l'applicazione Metro non può accedere direttamente al PC sottostante, utilizzando solo l'API WinRT e le funzionalità disponibili. Ma quando crei un servizio di back-end per accedere al PC e a tutti i dati lì, praticamente non viene più eseguito in sandbox.

L'unico "problema" è che l'utente deve installare manualmente questo servizio di back-end, ma non sarà un problema utilizzando un po 'di "ingegneria sociale": l'utente scarica l'app Metro "browser del PC", l'utente può sfogliare tutte le immagini, la musica e i video , utilizzando l'API WinRT, ma l'app mostra anche il messaggio in basso: "Scarica il powerpack del browser del nostro PC e sfoglia l'intero PC, GRATUITAMENTE"

L'utente viene reindirizzato alla pagina web, da cui può scaricare il classico programma di installazione desktop contenente il servizio di back-end "browser PC" per l'accesso ai file sull'intero PC dell'utente. Una volta installato questo servizio desktop, l'app Metro può rilevarlo e utilizzarlo per esplorare l'intero PC. L'utente è soddisfatto, ma la sandbox WinRT è compromessa.

Ovviamente questo non funzionerà su tablet ARM Windows 8. Utilizzando questa soluzione alternativa, potrebbe essere persino possibile creare client per app Metro per app desktop classiche come antivirus, client torrent / P2P, ecc.

Forse ho perso il punto, ma quando si attiva la funzionalità di reti private posso connettermi a un server locale in esecuzione (http) utilizzando l'indirizzo IP locale (non localhost). Ciò abilita il mio scenario in cui un'app winrt comunica con un'app desktop wpf