it-swarm.com.de

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

In einer Situation, in der Sie das UI-Frontend unter Verwendung des neuen Metro-Stils 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 einige erste Informationen geliefert 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 gibt auch keine Speicherzuordnungsdateien. 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 grobes Hack, das Abfragen erfordert und für den Benutzer sichtbar ist. - Pavel Minaev kommentiert diese Ausgabe

Wenn ich also normale Ansätze versage, habe ich darüber nachgedacht, Webservices zu verwenden oder Daten in eine Datenbank zu schreiben oder zu lesen, um eine Art von Kommunikation zu ermöglichen. Beides scheint zu viel zu sein, wenn die Prozesse auf demselben Computer ausgeführt werden.

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

118
dodgy_coder

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 die Vollduplex-Verbindung verwendet.

Dieser Beitrag beschreibt, welche Funktionalität unterstützt wird.

Ein Beispiel für meinen WCF-Server, den der Metro-Client verwenden kann, ist hier.

Denken Sie auch daran, dass Sie in Metro kein synchrones WCF verwenden können. Sie müssen Task - basierte Wrapper verwenden, die nur asynchron sind.

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

54
expert

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 großen Bildersitzungen machte, kam aus dem Publikum, um mit ihnen umzugehen. Laden Sie diese Sitzung herunter und lesen Sie die Fragen und Antworten http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C

Metro-Apps können sich nicht darauf verlassen, dass Desktop-Apps oder -Dienste auf dem Computer installiert sind. Und Desktop-Apps können sich nicht darauf verlassen, dass Metro-Apps ausgeführt werden, da sie jederzeit ausgesetzt werden können. Sie müssen anfangen, anders zu denken. Hören Sie Aleš in diesem Fall.

38
Kate Gregory

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 Enterprise-Szenarien unterstützt wird:

Vermittelte Windows-Laufzeitkomponenten 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 eine Vielzahl von Szenarien haben, für die der neue Anwendungsstil äußerst produktiv ist, enthält das Windows 8.1-Update eine neue Funktion mit dem Namen Brokered Windows Runtime Components for Side-Loaded anwendungen. Wir verwenden den Begriff IPC (prozessübergreifende Kommunikation), 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 Ein bekanntes Modell für Unternehmensentwickler, da Datenbankanwendungen und Anwendungen, die NT Services in Windows verwenden, eine ähnliche Multiprozessarchitektur aufweisen.

Die Implementierung dieses Ansatzes ist anfangs etwas kompliziert, ermöglicht jedoch eine umfassende Integration in alle Windows Store- und Desktop-Komponenten. Beachten Sie jedoch, dass derzeit keine öffentliche Windows Store-Zertifizierung besteht.

11
ig2r

Es gibt ein article on InfoQ zum Erstellen von lose gekoppelten Metro-Apps mit Protokollhandlern. Dies wird seit langem von Windows unterstützt und man könnte davon ausgehen, dass sich eine Desktop-Anwendung als Protokoll-Handler registriert und die Metro-Anwendung möglicherweise über diesen Mechanismus kommuniziert.

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

5
tronda

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 keine zusätzlichen Komponenten installiert werden müssen.

Ich habe es ausprobiert: es funktioniert auch nach Paketaktualisierung.

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

Hier wird erklärt, wie Sie die packageID für Ihre App ermitteln können: http://social.msdn.Microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396 -13ab9004c1cc/wie man die Appid einer App im Metro-Stil bekommt -

3
fgalliat

Christophe Nasarre hat gebloggt eine ziemlich hackige Methode, dies mit lokalen Dateien zu tun. Das Ergebnis ist die Kommunikation zwischen Desktop-App/Windows Store-App (im Blog als DA/WSA bezeichnet), ohne dass zwischen der Benutzeroberfläche der beiden Apps gewechselt werden muss. Er bloggte auch über eine andere weniger hackige Technik, die Protokollhandler involviert.

Beachten Sie, dass eine WSA, die mit einem DA kommuniziert, vom Store ausdrücklich untersagt wird App-Zertifizierungsanforderungen

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

... aber es schränkt nur "lokale Mechanismen" ein. Ich denke, man kann einen Webservice für die Weiterleitung der Kommunikation aufbauen.

3
twj

Es ist möglich, über einen lokalen 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 man die WinRT-Sandbox mit einem lokalen Dienst umgeht. Es benötigt noch eine Art "Social Engineering" oder eine direkte Anleitung zur Installation des Dienstes, aber es ist trotzdem möglich.
Ich bin mir jedoch nicht sicher, welche Zertifizierungsregeln für die Kommunikation mit "lokalen Diensten" gelten, wenn ich eine solche App zum Windows Store hinzufüge.

Beispiel hier

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

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

Der Benutzer wird auf eine Webseite umgeleitet, auf der er 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 kompromittiert.

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

2
Martin Suchan

Vielleicht habe ich den Punkt verpasst, aber wenn ich die Funktion für private Netzwerke aktiviere, 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

0
Wendelin