Comment une application Metro de Windows 8 peut-elle communiquer avec une application de bureau principale sur le même ordinateur?

Dans une situation où l’interface utilisateur utilise le nouveau style d’applications Metro pour Windows 8, et souhaiterait qu’elle communique avec une application .NET exécutée sur le bureau sur le même ordinateur local (une application de service Windows, par exemple).

Quelles formes de communication interprocessus sont disponibles entre l’application de métro et l’application de bureau?

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

Selon Martyn Lovell, il n’y a pas de mécanisme délibéré pour cela, et certains pourraient être utilisés intentionnellement. 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 lorsque vous vous connectez à 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 il s’agit d’un piratage assez grossier qui nécessite une interrogation et est visible par l’utilisateur. – Pavel Minaev commente cette question

Donc, à défaut d’approches normales, je pensais utiliser des services Web ou lire / écrire dans une firebase database pour obtenir une forme de communication, qui semblent excessives lorsque les processus sont exécutés sur le même ordinateur.

Est-ce que ce que je tente ici a du sens? Je peux voir un besoin pour une application de métro d’être l’interface utilisateur principale 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).

Je porte mon projet existant sur Win8 dès maintenant. Il consiste en un service Windows et 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 canaux nommés. J’ai fini par utiliser TcpBinding pour une connexion en duplex intégral.

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

Voici un exemple de serveur WCF que le client Metro peut consumr.

N’oubliez pas que vous ne pouvez pas utiliser WCF synchrone dans Metro. Vous devrez utiliser un wrapper basé sur des tâches qui est uniquement asynchrone.

Et merci pour votre question. J’ai été un bon sharepoint départ pour moi 🙂

Il y avait un certain nombre de questions comme celle-ci à la fin d’une // session / session à laquelle j’ai assisté. Aleš Holeček, l’exécutif qui a réalisé l’une des grandes séances de photo, est sorti du public pour les traiter. Même si vous n’êtes pas un développeur C ++, téléchargez cette session et regardez le Q & A. 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, car elles peuvent être suspendues à tout moment. Vous devez commencer à penser différemment. Écoutez Aleš sur celui-ci.

Notez qu’avec Windows 8.1 Update, la communication entre les applications 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 Entreprise:

Composants d’exécution Windows courtiers pour les applications Windows Store à chargement latéral

Citer:

Reconnaissant que les règles et les fonctions métier essentielles sont incorporées dans les actifs logiciels existants et que les entresockets disposent d’un large éventail de scénarios pour lesquels le nouveau style d’application sera hautement productif, la mise à jour Windows 8.1 inclut une nouvelle fonctionnalité appelée Composants Windows Runtime applications. Nous utilisons le terme IPC (communication inter-processus) pour décrire la possibilité d’exécuter des ressources logicielles de bureau existantes 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 firebase database et les applications utilisant les services NT de Windows partagent une architecture multiprocessus similaire.

Bien que l’implémentation de cette approche soit un peu compliquée au départ, elle permet une intégration profonde entre les composants Windows Store et les composants de bureau. Gardez à l’esprit que pour le moment, il ne passera pas la certificateion Windows Store publique.

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 a été supporté par Windows depuis longtemps et on pourrait prévoir un registre d’application de bureau lui-même en tant que gestionnaire de protocole et peut-être que l’application métropolitaine peut communiquer via ce mécanisme.

Je n’ai aucune idée si cela est possible, mais il pourrait être intéressant de vérifier.

Christophe Nasarre a blogué sur une manière plutôt pirate 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 certificateion de l’App Store

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

… mais cela restreint uniquement les “mécanismes locaux”. Je suppose donc que l’on peut créer un service Web pour acheminer les communications.

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

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

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

Je l’ai essayé: ça marche, même après la mise à jour du paquet.

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- l’app-appid-d’un-metro-style-app

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 mis en place il y a quelque temps une simple “preuve de concept”, comment contourner le sandbox WinRT en utilisant le service local. Il a encore besoin d’une sorte d’ingénierie sociale ou de guide direct pour l’installation du service, mais de toute façon, c’est possible.
Je ne suis pas sûr au sujet des règles de certificateion concernant la communication de «service local» lors de l’ajout d’une telle application au Windows Store.

Échantillon ici

Par conception, l’application Metro ne peut pas accéder directement au PC sous-jacent, uniquement à l’aide de l’API WinRT et des fonctionnalités disponibles. Mais lorsque vous créez un service d’arrière-plan pour accéder au PC et à toutes les données, il ne s’exécute plus dans un bac à sable.

Le seul “problème” est que l’utilisateur doit installer manuellement ce service back-end, mais cela ne posera pas de problème en utilisant une “ingénierie sociale”: Téléchargements utilisateur “Navigateur PC” Application Metro, l’utilisateur peut parcourir toutes les images, musique et vidéos , en utilisant l’API WinRT, mais l’application affiche également un message en bas: “Téléchargez notre Powerpack de 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 l’installateur de bureau classique contenant le service principal “PC browser” pour accéder aux fichiers sur le PC entier des utilisateurs. Une fois ce service de bureau installé, l’application Metro peut la détecter et l’utiliser pour parcourir l’ensemble du PC. L’utilisateur est content, 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.

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