Comment une application Metro dans Windows 8 peut-elle communiquer avec une application de bureau principale sur le même ordinateur?
Dans une situation où 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 s'exécutant sur le bureau sur le même ordinateur local (par exemple, une application de service Windows).
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, a déclaré:
Selon Martyn Lovell, il n'y a pas de 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 présents, par exemple, ni les fichiers mappés en mémoire. Il existe des sockets (y compris les 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 il s’agit d’un hack assez grossier qui nécessite une interrogation et qui est visible pour l’utilisateur. - Pavel Minaev commentant ce numéro
Donc, en échec des approches habituelles, je pensais utiliser des services Web ou lire/écrire dans une base de données afin de mettre en place une forme de communication, les deux semblant excessives lorsque les processus s'exécutent sur le même ordinateur.
Est-ce que ce que j'essaye ici a du sens? Je vois un besoin pour une application de métro d'être l'interface utilisateur frontale d'un service existant qui s'exécute sur le bureau. Ou préférez-vous simplement utiliser WPF pour l'interface utilisateur frontale exécutée sur le bureau (c'est-à-dire une application non métro).
Je porte mon projet existant sur Win8 en ce moment. Il consiste en un service Windows et une application de bac 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.
Ce post décrit quelle fonctionnalité est supportée.
Un exemple de mon serveur WCF que le client Metro peut consommer est ici.
N'oubliez pas non plus que vous ne pouvez pas utiliser une WCF synchrone dans Metro. Vous devrez utiliser un wrapper Task - qui est uniquement asynchrone.
Et merci pour votre question. J'étais un bon point de départ pour moi :)
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 participé à l'une des séances de grande image, est sorti du public pour le 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 car elles peuvent être suspendues à tout moment. Vous devez commencer à penser différemment. Écoutez Aleš sur celui-ci.
Notez qu'avec la mise à jour 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 des 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 Brokered Windows Runtime Components pour les applications à chargement latéral. applications. Nous utilisons le terme IPC (communication inter-processus) pour décrire la possibilité d'exécuter des actifs logiciels de bureau existants dans un processus (composant de bureau) tout en interagissant avec ce code dans une application du Windows Store. un modèle familier pour les développeurs d'entreprise, les applications de base de données et les applications utilisant les services NT de Windows partagent une architecture multi-processus similaire.
Bien que la mise en œuvre de cette approche soit un peu complexe à l’origine, elle permet une intégration poussée entre les composants Windows Store et Desktop. N'oubliez pas que pour l'instant, il ne passera pas la certification publique du Windows Store.
Il existe un article sur InfoQ sur la manière 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 que l’application métro puisse également communiquer via ce mécanisme.
Je ne sais pas si cela est possible, mais cela pourrait être intéressant à vérifier.
Si vous pensez pouvoir effectuer une opération de commande 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 d'extra à installer.
Je l'ai essayé: cela fonctionne 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 de votre application: http://social.msdn.Microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how- to-get-the-appid-of-a-metro-style-app -
Christophe Nasarre a blogué une façon plutôt compliquée de le faire en utilisant des fichiers locaux. Le résultat est une communication entre une application de bureau/une application Windows Store (appelée DA/WSA dans le blog), sans avoir à basculer entre l'interface utilisateur des deux applications. Il a également publié un blog sur une autre technique moins sophistiquée impliquant des gestionnaires de protocole.
Notez qu'avoir un WSA qui communique avec un DA est explicitement interdit par le magasin Exigences de certification de l'application
Les applications du 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 ne limite que les "mécanismes locaux". Je suppose donc que l’on peut créer un service Web pour acheminer les communications.
Il est possible de communiquer sur le même ordinateur depuis l'application Metro vers une application de bureau via le service local. J'ai mis en place il y a quelque temps une simple "preuve de concept", qui permet de contourner le bac à sable WinRT à l'aide du service local. Il faut encore une sorte d'ingénierie sociale ou un guide direct pour l'installation du service, mais de toute façon, c'est possible.
Cependant, je ne suis pas sûr des règles de certification relatives à la communication "Service local" lors de l'ajout d'une telle application à Windows Store.
De par sa 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 principal permettant d'accéder au PC et à toutes les données, il ne fonctionne plus dans le bac à sable.
Le seul "problème" est que l'utilisateur doit installer manuellement ce service d'arrière-plan, mais l'utilisation de "l'ingénierie sociale" ne posera pas de problème: L'utilisateur télécharge l'application Metro "navigateur PC", l'utilisateur peut parcourir toutes les photos, la musique et les vidéos. , en utilisant WinRT API, mais l’application affiche également un message en bas: "Téléchargez notre powerpack de navigateur PC et parcourez l’ensemble de votre PC, GRATUITEMENT"
L'utilisateur est redirigé vers une page Web à partir de laquelle l'utilisateur peut télécharger le programme d'installation de bureau classique contenant le service principal "Navigateur de PC" pour accéder aux fichiers sur l'ensemble du PC de l'utilisateur. 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 sous Windows 8 ARM tablettes. Cette solution de contournement pourrait permettre de créer des clients d’applications Metro pour des applications de bureau classiques telles que des antivirus, des clients torrent/P2P, etc.
J'ai peut-être manqué le but mais lors de l'activation de la fonctionnalité Réseaux privés, je peux me connecter à un serveur local (http) utilisant l'adresse IP locale (pas localhost). Cela active mon scénario où une application winrt communique avec une application de bureau wpf