Comment une application Metro dans Windows 8 peut-elle communiquer avec une application de bureau principale sur la même machine?

120

Dans une situation où l'interface de l'interface utilisateur est construite à l'aide du nouveau style d'applications Metro pour Windows 8 et que vous souhaitez qu'elle communique avec une application .NET exécutée sur le bureau sur la même machine locale (par exemple, une application de service Windows).

Quelles formes de communication interprocessus sont disponibles entre l'application Metro et l'application de bureau?

Merci à Pavel Minaev de l'équipe Visual Studio, qui a fourni quelques informations initiales ici dans un commentaire, cité:

Selon Martyn Lovell, il n'y a aucun mécanisme délibéré pour cela, et certains qui pourraient être utilisés pour cela sont intentionnellement restreints. Les canaux nommés ne sont pas là, par exemple, ni les fichiers mappés en mémoire. Il existe des sockets (y compris des sockets serveur), mais lors de la connexion à localhost, vous ne pouvez vous connecter qu'à la même application. Vous pouvez utiliser des fichiers normaux dans l'un des "dossiers connus" partagés (Documents, Images, etc.), mais c'est un hack assez grossier qui nécessite une interrogation et qui est visible par l'utilisateur. - Pavel Minaev commentant cette question

Donc, à défaut d'approches normales, je pensais utiliser des services Web ou lire / écrire dans une base de données afin d'obtenir une certaine forme de communication, ce qui semble excessif lorsque les processus s'exécutent sur la même machine.

Ce que je tente ici a-t-il un sens? Je peux voir la nécessité pour une application de métro d'être l'interface utilisateur frontale d'un service existant qui s'exécute sur le bureau. Ou est-il préférable d'utiliser simplement WPF pour l'interface utilisateur frontale exécutée sur le bureau (c'est-à-dire une application non métropolitaine).

— dodgy_coder
source

2

Qu'en est-il d'un service WCF local?

— Gleno le

2

@Gleno qui serait couvert de "penser à utiliser des services Web" dans la question. Cela dit, je me demande si cela fonctionnera même - si l'implémentation de la bibliothèque cliente WCF fournie dans .NET Core est construite sur des sockets WinRT, alors probablement la même restriction "pas d'hôte local" s'appliquerait. Cela doit être vérifié.

— Pavel Minaev

1

Il semble que NetNamedPipeBinding et NetTcpBinding de WCF (sur localhost) ne seraient pas disponibles de toute façon en raison des restrictions dans le métro. Cela laisserait les services Web ou les liaisons MSMQ? Je ne sais pas si WCF lui-même est disponible dans le métro pour être honnête.

— dodgy_coder

6

Permettez-moi de retourner votre question et de vous demander: Que se passe-t-il si le service de bureau avec lequel vous communiquez n'est pas présent? N'oubliez pas que votre application ne peut être installée qu'à partir du magasin et qu'elle ne peut donc pas compter sur la présence du service de bureau.

— RéintégrerMonica Larry Osterman

3

Il semble que les entreprises peuvent charger des applications personnalisées et contourner le Windows Store. Si tel est le cas, il serait logique que vous puissiez supposer que certaines applications s'exécutent dans l'environnement de l'entreprise. Cela dit, je pense que l'affiche originale devrait utiliser une interface WPF de bureau à ses fins.

— Ankur Goel

54

Je porte mon projet existant sur Win8 en ce moment. Il se compose d'un service Windows et d'une application de plateau qui se parlent via NamedPipes WCF. Comme vous le savez peut-être déjà, Metro ne prend pas en charge les tuyaux nommés. J'ai fini par utiliser TcpBinding pour une connexion full duplex.

Cet article décrit les fonctionnalités prises en charge.

Un exemple de mon serveur WCF que le client Metro peut consommer est ici .

Gardez également à l'esprit que vous ne pouvez pas utiliser WCF synchrone dans Metro. Vous devrez utiliser un wrapper basé sur les tâches qui est uniquement asynchrone.

Et merci pour votre question. J'étais un bon point de départ pour moi :)

— expert
source

7

Merci pour cela ... c'est d'une grande aide. C'est bien de voir une réponse pratique au lieu de simplement se faire dire que cela ne devrait pas / ne peut pas être fait.

— dodgy_coder

1

C'est peut-être une question stupide ... mais vous pouvez vous connecter à localhost en utilisant votre échantillon ou non? La question à laquelle vous créez un lien montre les éléments internes de Visual Studio (je l'ai déduit du chemin, mais si je me trompe, veuillez me corriger). WCF (combiné avec localhost) fonctionne-t-il en dehors de WCF?

— dzendras

1

@dzendras Bien sûr, cela fonctionnera. Cela fonctionnera également avec localhost.

— expert

3

Je doute qu'une application comme celle-ci passe la certification Store, cependant.

— Ani

6

Si tel est le cas, je pense que cela pourrait être cité "3.9 Toute la logique d'application doit provenir et résider dans votre package d'application. Votre application ne doit pas tenter de modifier ou d'étendre le contenu du package via une forme d'inclusion dynamique de code ou des données qui modifient la façon dont l'application interagit avec Windows Runtime ou se comporte par rapport à la stratégie du Store. Il n'est pas permis, par exemple, de télécharger un script distant et d'exécuter ensuite ce script dans le contexte local de votre package d'application. "

— Ani

38

Il y avait un certain nombre de questions comme celle-ci à la fin d'une // build / session à laquelle j'ai assisté. Aleš Holeček, l'exécutif qui a fait l'une des grandes séances photo, est sorti du public pour les gérer. Même si vous n'êtes pas un développeur C ++, téléchargez cette session et regardez les questions et réponses http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C

Les applications Metro ne peuvent pas compter sur les applications de bureau ou les services installés sur la machine. Et les applications de bureau ne peuvent pas compter sur les applications Metro en cours d'exécution puisqu'elles peuvent être suspendues à tout moment. Vous devez commencer à penser différemment. Écoutez Aleš sur celui-ci.

— Kate Gregory
source

6

Cette question exacte semble être posée à 47:20 dans la vidéo.

— Pavel Minaev le

3

... et un de plus à 55h00. La réponse, en général, semble être "non, vous ne pouvez pas faire ça".

— Pavel Minaev le

1

@dodgy_coder Je ne suis pas sûr que WCF / TCP (ou HTTP) fonctionnerait sur la même machine. Si le bac à sable ne vous permet pas de vous connecter localhostdirectement via un socket TCP, pourquoi vous permettrait-il de faire de même via WCF?

— Pavel Minaev

2

Fait intéressant, il existe un support intégré pour la communication entre deux applications métropolitaines via des contrats de partage, mais cela semble être similaire dans l'utilisation du presse-papiers, et pour le transfert à sens unique d'une application source vers une application cible, plutôt que pour implémenter, disons deux protocole de communication -way.

— dodgy_coder du

4

Il me semble que les applications LOB Metro à chargement latéral n'auraient aucun problème en fonction d'une application ou d'un service de bureau installé. J'ai du mal à croire que ce scénario très pratique ne sera pas pris en charge. Avec Silverlight, nous avons vu une augmentation progressive des capacités d'interopérabilité de bureau / natives ... Je suis à peu près sûr que quelque chose dans ces scénarios (canaux nommés, ou fichiers mappés en mémoire, ou quelque chose ...) sera pris en charge (avec des documents d'orientation) A l'avenir.

— David Cuccia

11

Notez qu'avec la mise à jour de Windows 8.1, la communication entre les applications du Windows Store et les composants de bureau écrits en C # pour .NET 4.5+ est désormais officiellement prise en charge pour les applications à chargement latéral dans les scénarios d'entreprise:

Composants Windows Runtime négociés pour les applications Windows Store à chargement latéral

Citer:

Reconnaissant que les fonctions et règles métier critiques sont incorporées dans les actifs logiciels existants et que les entreprises disposent d'une grande variété de scénarios pour lesquels le nouveau style d'application sera hautement productif, la mise à jour de Windows 8.1 inclut une nouvelle fonctionnalité appelée Composants Windows Runtime Brokered pour les applications. Nous utilisons le terme IPC (communication inter-processus) pour décrire la capacité d'exécuter des actifs logiciels de bureau existants dans un processus (composant de bureau) tout en interagissant avec ce code dans une application Windows Store. Il s'agit d'un modèle familier aux développeurs d'entreprise car les applications de base de données et les applications utilisant les services NT dans Windows partagent une architecture multi-processus similaire.

Bien que la mise en œuvre de cette approche soit un peu compliquée au départ, elle permet une intégration profonde entre le Windows Store et les composants de bureau. Gardez simplement à l'esprit que pour le moment, il ne passera pas la certification publique du Windows Store.

— ig2r
source

5

Il existe un article sur InfoQ sur la façon de créer des applications Metro faiblement couplées avec des gestionnaires de protocole. C'est quelque chose qui est pris en charge par Windows depuis longtemps et on pourrait prévoir qu'une application de bureau s'enregistre elle-même en tant que gestionnaire de protocole et peut-être que l'application de métro peut communiquer via ce mécanisme.

Je ne sais pas si cela est possible, mais il pourrait être intéressant de vérifier.

— tronda
source

L'article dit: "La façon dont vous pouvez faire cela dans Metro [passer à un autre flux de travail dans une application différente - parce que votre application est censée être petite et très ciblée] consiste à tirer parti des protocoles. Pour notre exemple ci-dessus, le protocole peut ressembler à "Acme-stock-purchase: // client = 123 & stock = XYZ". " - Qu'est-ce que cela signifie techniquement, "tirer parti des protocoles"?

— Lumi

Le problème avec cette approche est que ce n'est qu'une communication à sens unique.

— expert

3

Christophe Nasarre a écrit sur un blog sur une façon plutôt hacky de le faire en utilisant des fichiers locaux. Le résultat est une communication entre l'application de bureau / l'application Windows Store (appelée DA / WSA dans le blog), sans avoir à basculer entre l'interface utilisateur des deux applications. Il a également blogué sur une autre technique moins piratée impliquant des gestionnaires de protocole.

Notez que le fait d'avoir un WSA qui communique avec un DA est explicitement interdit par les exigences de certification de l'App Store

Les applications du Windows Store ne doivent pas communiquer avec les applications ou services de bureau locaux via des mécanismes locaux, y compris via des fichiers et des clés de registre.

... mais il ne restreint que les "mécanismes locaux". Je suppose donc que l'on peut créer un service Web pour acheminer les communications.

— twj
source

3

Si vous pensez que vous pouvez effectuer une opération cmd manuelle supplémentaire, vous pouvez essayer:

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

CheckNetIsolation.exe est inclus dans l'installation de winRT, il n'y a donc rien de plus à installer.

Je l'ai essayé: cela fonctionne, même après la mise à jour du package.

Comme indiqué sur: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

Ici, il est expliqué comment trouver le packageID pour votre application: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get- le-appid-of-a-metro-style-app-

— fgalliat
source

Je voulais pouvoir communiquer avec localhost pour une application interne et je ne pouvais le faire que sur les ordinateurs n'exécutant pas VS en utilisant cette commande.

— adosaiguas

2

Il est possible de communiquer sur la même machine depuis l'application Metro vers l'application de bureau en utilisant le service local. J'ai implémenté il y a quelque temps une simple «preuve de concept», comment contourner le bac à sable WinRT en utilisant le service local. Il a encore besoin d'une sorte d '«ingénierie sociale» ou d'un guide direct pour installer le service, mais de toute façon, c'est possible.
Je ne suis pas sûr des règles de certification concernant la communication «service local» lors de l'ajout d'une telle application au Windows Store.

Échantillon ici

De par sa conception, l'application Metro ne peut pas accéder directement au PC sous-jacent, en utilisant uniquement l'API WinRT et les fonctionnalités disponibles. Mais lorsque vous créez un service back-end pour accéder au PC et à toutes les données qu'il contient, il ne fonctionne plus dans le bac à sable.

Le seul "problème" est que l'utilisateur doit installer manuellement ce service back-end, mais ce ne sera pas un problème en utilisant une "ingénierie sociale": l'utilisateur télécharge l'application Metro "navigateur PC", l'utilisateur peut parcourir toutes les photos, musiques et vidéos , en utilisant l'API WinRT, mais l'application affiche également un message en bas: "Téléchargez notre pack d'alimentation pour navigateur PC et parcourez votre PC entier, GRATUITEMENT"

L'utilisateur est redirigé vers la page Web, à partir de laquelle l'utilisateur peut télécharger le programme d'installation de bureau classique contenant le service back-end "navigateur PC" pour accéder aux fichiers sur tout le PC des utilisateurs. Une fois ce service de bureau installé, l'application Metro peut le détecter et l'utiliser pour parcourir l'ensemble du PC. L'utilisateur est satisfait, mais le bac à sable WinRT est compromis.

Bien sûr, cela ne fonctionnera pas sur les tablettes Windows 8 ARM. En utilisant cette solution de contournement, il pourrait même être possible de créer des clients d'applications Metro pour des applications de bureau classiques telles que des antivirus, des clients torrent / P2P, etc.

— Martin Suchan
source

3

Je ne sais pas pourquoi vous devez mentionner l'ingénierie sociale ... puisque la question d'origine parle d'une application / service de bureau parlant à une application de métro, il est prévu que l'utilisateur devra installer l'application / service de bureau séparément. Alors, quelle méthode de communication avez-vous utilisée entre le service de bureau et l'application de métro?

— dodgy_coder

0

Peut-être ai-je manqué le point, mais lors de l'activation de la capacité Réseaux privés, je peux me connecter à un serveur local (http) en utilisant l'adresse IP locale (pas localhost). Cela active mon scénario où une application winrt communique avec une application de bureau wpf

— Wendelin
source