Wie kann eine Metro-App in Windows 8 mit einer Backend-Desktop-App auf demselben Computer kommunizieren?


120

In einer Situation, in der Sie das UI-Frontend mit dem neuen Metro-Stil von Apps für Windows 8 erstellt haben und möchten, dass es mit einer .NET-Anwendung kommuniziert, die auf dem Desktop auf demselben lokalen Computer ausgeführt wird (z. B. einer Windows-Dienst-App).

Welche Formen der Interprozesskommunikation stehen zwischen der Metro-App und der Desktop-App zur Verfügung?

Vielen Dank an Pavel Minaev vom Visual Studio-Team, der hier in einem Kommentar erste Informationen zur Verfügung gestellt hat.

Laut Martyn Lovell gibt es dafür keinen absichtlichen Mechanismus, und einige, die dafür verwendet werden könnten, sind absichtlich eingeschränkt. Named Pipes sind beispielsweise nicht vorhanden, und es sind auch keine Speicherzuordnungsdateien vorhanden. Es gibt Sockets (einschließlich Server-Sockets), aber wenn Sie eine Verbindung zu localhost herstellen, können Sie nur eine Verbindung zu derselben App herstellen. Sie könnten normale Dateien in einem der freigegebenen "bekannten Ordner" (Dokumente, Bilder usw.) verwenden, aber das ist ein ziemlich grober Hack, der eine Abfrage erfordert und für den Benutzer sichtbar ist. - Pavel Minaev kommentiert dieses Problem

Wenn ich also an normalen Ansätzen scheiterte, dachte ich daran, Webdienste zu verwenden oder in eine Datenbank zu lesen / schreiben, um eine Form der Kommunikation zu erreichen. Beides scheint übertrieben, wenn die Prozesse auf demselben Computer ausgeführt werden.

Ist das, was ich hier versuche, sinnvoll? Ich sehe, dass eine Metro-App die Frontend-Benutzeroberfläche für einen vorhandenen Dienst sein muss, der auf dem Desktop ausgeführt wird. Oder ist es besser, WPF nur für die Frontend-Benutzeroberfläche zu verwenden, die auf dem Desktop ausgeführt wird (dh eine Nicht-Metro-App).


2
Was ist mit einem lokalen WCF-Dienst?
Gleno

2
@Gleno, das in der Frage von "Denken über die Verwendung von Webdiensten" abgedeckt würde. Trotzdem frage ich mich, ob es überhaupt funktionieren wird - wenn die Implementierung der WCF-Clientbibliothek, die in .NET Core bereitgestellt wird, auf WinRT-Sockets basiert, würde vermutlich dieselbe Einschränkung "kein lokaler Host" gelten. Dies muss überprüft werden.
Pavel Minaev

1
Es sieht so aus, als wären NetNamedPipeBinding und NetTcpBinding (über localhost) von WCF aufgrund der Einschränkungen in der Metro ohnehin nicht verfügbar. Das würde Webdienste oder MSMQ-Bindungen hinterlassen? Ich bin mir nicht sicher, ob WCF selbst in der U-Bahn verfügbar ist, um ehrlich zu sein.
dodgy_coder

6
Lassen Sie mich Ihre Frage umdrehen und Sie fragen: Was passiert, wenn der Desktop-Dienst, mit dem Sie kommunizieren, nicht vorhanden ist? Denken Sie daran, dass Ihre Anwendung nur aus dem Store installiert werden kann und sich daher nicht auf das Vorhandensein des Desktop-Dienstes verlassen kann.
ReinstateMonica Larry Osterman

3
Es scheint, dass Unternehmen benutzerdefinierte Apps von der Seite laden und den Windows Store umgehen können. In diesem Fall ist es sinnvoll, davon auszugehen, dass einige Anwendungen in der Unternehmensumgebung ausgeführt werden. Trotzdem denke ich, dass das Originalposter für seine Zwecke ein Desktop-WPF-Frontend verwenden sollte.
Ankur Goel

Antworten:


54

Ich portiere gerade mein bestehendes Projekt auf Win8. Es besteht aus Windows-Dienst und Tray-Anwendung, die über NamedPipes WCF miteinander kommunizieren. Wie Sie vielleicht bereits wissen, unterstützt Metro keine Named Pipes. Am Ende habe ich TcpBinding für eine Vollduplexverbindung verwendet.

Dieser Beitrag beschreibt, welche Funktionen unterstützt werden.

Probe meiner WCF - Server , dass Metro - Client verbrauchen kann , ist hier .

Beachten Sie auch, dass Sie in Metro kein synchrones WCF verwenden können. Sie müssen verwenden Aufgabe , die nur asynchron -basierte Wrapper.

Und danke für deine Frage. Ich war ein guter Ausgangspunkt für mich :)


7
Danke dafür ... das ist eine große Hilfe. Es ist gut, eine praktische Antwort zu sehen, anstatt nur zu erfahren, dass dies nicht getan werden sollte / kann.
dodgy_coder

1
Es mag eine dumme Frage sein ... aber Sie können sich mit Ihrem Beispiel mit localhost verbinden oder nicht? Die Frage, auf die Sie verlinken, zeigt die Interna von Visual Studio (ich habe sie aus dem Pfad abgeleitet, aber wenn ich falsch liege, korrigieren Sie mich bitte). Funktioniert WCF (kombiniert mit localhost) außerhalb von WCF?
Dzendras

1
@dzendras Sicher, es wird funktionieren. Es wird auch mit localhost funktionieren.
Experte

3
Ich bezweifle jedoch, dass eine solche App die Store-Zertifizierung bestehen würde.
Ani

6
Wenn überhaupt, ist dies die Regel, von der ich denke, dass sie zitiert werden könnte. "3.9 Die gesamte App-Logik muss aus Ihrem App-Paket stammen und sich in diesem befinden. Ihre App darf nicht versuchen, den gepackten Inhalt durch irgendeine Form der dynamischen Einbeziehung von Code oder Code zu ändern oder zu erweitern Daten, die die Interaktion der Anwendung mit der Windows-Laufzeit ändern oder sich in Bezug auf die Speicherrichtlinie verhalten. Es ist beispielsweise nicht zulässig, ein Remote-Skript herunterzuladen und dieses Skript anschließend im lokalen Kontext Ihres App-Pakets auszuführen. "
Ani

38

Am Ende einer // Build / Session, an der ich teilgenommen habe, gab es eine Reihe solcher Fragen. Aleš Holeček, der Geschäftsführer, der eine der Big-Picture-Sessions durchgeführt hat, kam aus dem Publikum, um sich um sie zu kümmern. Auch wenn Sie kein C ++ - Entwickler sind, laden Sie diese Sitzung herunter und sehen Sie sich die Fragen und Antworten an. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C

Metro-Apps können nicht damit rechnen, dass Desktop-Apps oder -Dienste auf dem Computer installiert werden. Und Desktop-Apps können nicht mit der Ausführung von Metro-Apps rechnen, da sie jederzeit angehalten werden können. Sie müssen anfangen, anders zu denken. Hören Sie sich Aleš an.


6
Diese genaue Frage scheint im Video um 47:20 Uhr gestellt zu werden.
Pavel Minaev

3
... und noch eine um 55:00. Die Antwort scheint im Allgemeinen "Nein, das können Sie nicht tun" zu sein.
Pavel Minaev

1
@dodgy_coder Ich bin nicht sicher, ob WCF / TCP (oder HTTP) auf demselben Computer funktionieren würde. Wenn Sie in der Sandbox keine localhostdirekte Verbindung über einen TCP-Socket herstellen können, warum können Sie dies dann auch über WCF tun?
Pavel Minaev

2
Interessanterweise ist die Unterstützung für die Kommunikation zwischen zwei Metro-Apps über Freigabeverträge integriert , dies scheint jedoch in der Verwendung der Zwischenablage ähnlich zu sein und für die Übertragung in eine Richtung von einer Quell-App zu einer Ziel-App, anstatt beispielsweise eine Zwei zu implementieren -way Kommunikationsprotokoll.
dodgy_coder

4
Mir scheint, dass seitlich geladene LOB Metro-Apps abhängig von einer installierten Desktop-App oder einem installierten Dienst kein Problem haben würden. Es fällt mir schwer zu glauben, dass dieses sehr praktische Szenario nicht unterstützt wird. Mit Silverlight haben wir eine allmähliche Zunahme der Desktop- / nativen Interop-Funktionen festgestellt. Ich bin mir ziemlich sicher, dass etwas in diesen Szenarien (Named Pipes oder speicherabgebildete Dateien oder etwas ...) (mit Anleitungen) unterstützt wird. in der Zukunft.
David Cuccia

11

Beachten Sie, dass mit Windows 8.1 Update die Kommunikation zwischen Windows Store-Apps und Desktop-Komponenten, die in C # für .NET 4.5+ geschrieben wurden, jetzt offiziell für seitlich geladene Anwendungen in Unternehmensszenarien unterstützt wird:

Brokered Windows Runtime Components für seitlich geladene Windows Store-Apps

Zitieren:

In Anbetracht der Tatsache, dass wichtige Geschäftsfunktionen und -regeln in vorhandenen Software-Assets enthalten sind und Unternehmen über eine Vielzahl von Szenarien verfügen, für die der neue Anwendungsstil äußerst produktiv sein wird, enthält das Windows 8.1-Update eine neue Funktion namens Brokered Windows Runtime Components für Side-Loaded Anwendungen. Wir verwenden den Begriff IPC (Interprozesskommunikation), um die Fähigkeit zu beschreiben, vorhandene Desktop-Software-Assets in einem Prozess (Desktop-Komponente) auszuführen, während mit diesem Code in einer Windows Store-App interagiert wird. Dies ist ein bekanntes Modell für Unternehmensentwickler, da Datenbankanwendungen und Anwendungen, die NT Services in Windows verwenden, eine ähnliche Multiprozessarchitektur aufweisen.

Obwohl die Implementierung dieses Ansatzes anfangs etwas kompliziert ist, ermöglicht sie eine umfassende Integration zwischen Windows Store- und Desktop-Komponenten. Beachten Sie jedoch, dass die öffentliche Windows Store-Zertifizierung vorerst nicht bestanden wird.


5

Es gibt einen Artikel über InfoQ darüber , wie mit Protokollhandler losen gekoppelten Metro - Apps zu bauen. Dies wird von Windows seit langem unterstützt, und man könnte vorhersehen, dass sich eine Desktop-Anwendung als Protokollhandler registriert und die Metro-Anwendung möglicherweise über diesen Mechanismus kommunizieren kann.

Ich habe keine Ahnung, ob dies möglich ist, aber es könnte interessant sein, es zu überprüfen.


In dem Artikel heißt es: "Sie können dies in Metro tun [zu einem anderen Workflow in einer anderen Anwendung wechseln - da Ihre App klein und stark fokussiert sein soll], indem Sie Protokolle nutzen. In unserem obigen Beispiel sieht das Protokoll möglicherweise so aus "Acme-Aktienkauf: // client = 123 & stock = XYZ". - Was bedeutet es technisch, "Protokolle zu nutzen"?
Lumi

Das Problem bei diesem Ansatz ist, dass es sich nur um eine Einwegkommunikation handelt.
Experte

3

Christophe Nasarre hat gebloggt über einen ziemlich hacky Weg , es zu tun , lokale Dateien. Das Ergebnis ist eine Kommunikation zwischen Desktop-App / Windows Store-App (im Blog als DA / WSA bezeichnet), ohne zwischen der Benutzeroberfläche der beiden Apps wechseln zu müssen. Er bloggte auch über eine andere weniger hackige Technik, an der Protokollhandler beteiligt waren.

Beachten Sie, dass eine WSA, die mit einem DA kommuniziert, durch die Zertifizierungsanforderungen für die Store- App ausdrücklich verboten ist

Windows Store-Apps dürfen nicht über lokale Mechanismen, einschließlich Dateien und Registrierungsschlüssel, mit lokalen Desktopanwendungen oder -diensten kommunizieren.

... aber es schränkt nur "lokale Mechanismen" ein. Ich denke, man kann einen Webdienst für das Routing der Kommunikation erstellen.


3

Wenn Sie der Meinung sind, dass Sie eine zusätzliche manuelle Cmd-Operation ausführen können, können Sie Folgendes versuchen:

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

CheckNetIsolation.exe ist in der winRT-Installation enthalten, sodass nichts extra installiert werden muss.

Ich habe es versucht: Es funktioniert auch nach der Aktualisierung des Pakets.

Wie gezeigt unter: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

Hier erfahren Sie, wie Sie die Paket-ID für Ihre App ermitteln: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get- die-appid-of-a-metro-style-app-


Ich wollte in der Lage sein, mit localhost für eine interne Anwendung zu kommunizieren, und ich konnte dies nur auf Computern ermöglichen, auf denen VS nicht mit diesem Befehl ausgeführt wird.
Adosaiguas

2

Es ist möglich, über denselben Dienst von der Metro-App zur Desktop-App auf demselben Computer zu kommunizieren. Ich habe vor einiger Zeit einen einfachen "Proof of Concept" implementiert, wie die WinRT-Sandbox mithilfe des lokalen Dienstes umgangen werden kann. Für die Installation des Dienstes ist noch eine Art "Social Engineering" oder eine direkte Anleitung erforderlich, aber es ist trotzdem möglich.
Ich bin mir jedoch nicht sicher, welche Zertifizierungsregeln für die Kommunikation mit "lokalen Diensten" beim Hinzufügen einer solchen App zum Windows Store gelten.

Probe hier

Die Metro-Anwendung kann nicht direkt auf den zugrunde liegenden PC zugreifen, sondern nur über die WinRT-API und die verfügbaren Funktionen. Wenn Sie jedoch einen Back-End-Dienst für den Zugriff auf den PC und alle dortigen Daten erstellen, wird dieser im Grunde nicht mehr in der Sandbox ausgeführt.

Das einzige "Problem" besteht darin, dass der Benutzer diesen Back-End-Dienst manuell installieren muss. Mit "Social Engineering" ist dies jedoch kein Problem: Der Benutzer lädt die Metro-App "PC-Browser" herunter und kann alle Bilder, Musik und Videos durchsuchen mit der WinRT-API, aber die App zeigt auch die Meldung unten an: "Laden Sie unser PC-Browser-Powerpack herunter und durchsuchen Sie Ihren gesamten PC KOSTENLOS."

Der Benutzer wird zur Webseite weitergeleitet, von der aus der Benutzer das klassische Desktop-Installationsprogramm mit dem Back-End-Dienst "PC-Browser" herunterladen kann, um auf Dateien auf dem gesamten PC des Benutzers zuzugreifen. Sobald dieser Desktop-Dienst installiert ist, kann die Metro-App ihn erkennen und zum Durchsuchen des gesamten PCs verwenden. Der Benutzer ist zufrieden, aber die WinRT-Sandbox ist gefährdet.

Dies funktioniert natürlich nicht auf Windows 8 ARM-Tablets. Mit dieser Problemumgehung können sogar Metro-App-Clients für klassische Desktop-Apps wie Virenschutzprogramme, Torrent- / P2P-Clients usw. erstellt werden.


3
Sie sind sich nicht sicher, warum Sie über Social Engineering sprechen müssen. Da es sich bei der ursprünglichen Frage um eine Desktop-App / einen Desktop-Dienst handelt, die / der mit einer Metro-App spricht, wird erwartet, dass der Benutzer die Desktop-App / den Desktop-Dienst separat installieren muss. Welche Kommunikationsmethode haben Sie zwischen dem Desktop-Dienst und der Metro-App verwendet?
dodgy_coder

0

Vielleicht habe ich den Punkt verpasst, aber beim Aktivieren der Funktion "Private Netzwerke" kann ich über die lokale IP-Adresse (nicht localhost) eine Verbindung zu einem lokal laufenden (http) Server herstellen. Dies ermöglicht mein Szenario, in dem eine winrt-App mit einer wpf-Desktop-App kommuniziert

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.