Comment communiquer avec un service Windows à partir d'une application qui interagit avec le bureau?

Question

Avec .Net, quel est le meilleur moyen d’interagir avec un service (c.-à-d. comment la plupart des applications Tray communiquent-elles avec leurs serveurs)? Il serait préférable que cette méthode soit également multiplate-forme (travaillant en Mono, donc je suppose que la communication à distance est terminée?)

Modifier:

Vous avez oublié de mentionner, nous devons toujours prendre en charge les machines Windows 2000 sur le terrain, de sorte que WCF et les versions supérieures à .Net 2.0 ne volent pas.

Answer 1

Sachez que si vous envisagez de déployer éventuellement sur Windows Vista ou Windows Server 2008, cela ne fonctionne pas de nombreuses façons. Ceci est dû à l'introduction d'une nouvelle fonctionnalité de sécurité appelée & "Session 0 Isolation &";

La plupart des services Windows ont été déplacés pour s'exécuter dans la session 0 afin de les isoler correctement du reste du système. Une extension de ceci est que le premier utilisateur qui se connecte au système n'est plus placé dans la session n ° 0, il est placé dans la session 1. Et donc, l'isolation rompra le code qui établit certains types de communication entre les services et les applications de bureau.

Le meilleur moyen d'écrire du code aujourd'hui qui fonctionnera sous Vista et Server 2008 lors de la communication entre services et applications consiste à utiliser une API inter-processus appropriée, telle que RPC, des tubes nommés, etc. N'utilisez pas SendMessage / PostMessage comme cela échouera sous l’isolement de la session 0.

http://www.microsoft.com/whdc/system/vista/ services.mspx

Maintenant, compte tenu de vos besoins, vous allez être dans le pétrin. En ce qui concerne les problèmes multi-plateformes, je ne sais pas si Remoting sera pris en charge. Vous devrez peut-être vous déplacer et revenir aux sockets: http://msdn.microsoft.com/en-us/library/system.net.sockets.aspx

Answer 2

S'il s'agit d'une application de plateau et non d'un véritable service, méfiez-vous de la façon dont vous configurez vos communications si vous utilisez des canaux ou TCP / IP. Si plusieurs utilisateurs sont connectés à une machine (Citrix, Remote Desktop) et que chaque utilisateur lance une application de bac & «Service &» ;, vous pouvez alors vous retrouver dans une situation où plusieurs processus essaient d'utiliser le même port ou pipe bien connu. Bien sûr, cela ne pose pas de problème si vous ne prévoyez pas de prendre en charge plusieurs canaux ou si vous avez un vrai service, par opposition à une application de plateau fonctionnant dans chaque shell utilisateur.

Answer 3

Demandez à votre service d’écouter 127.0.0.1 sur un port prédéfini doté d’un vieux socket TCP. Connectez-vous à ce port à partir de votre application de bureau.

C’est simple, c’est une plate-forme complètement transversale.

Answer 4

Est-ce que l’un d’entre vous a réellement essayé d’utiliser la communication à distance avec Mono? Cela fonctionne très bien. Vous pouvez rencontrer des cas critiques, mais cela est très peu probable. Il vous suffit de tester votre application pour la mise à niveau multi-plateforme (MS.Net & Lt; - & Gt; Mono) de temps à autre afin d’attraper tous les problèmes éventuels. Et commençons par un récent Mono, la 2.4.2 est actuelle.

Answer 5

La communication à distance est une option, mais elle n'est pas multiplateforme. Vous pouvez également utiliser des canaux nommés, des événements IPC ou du noyau.

Answer 6

Assez curieusement, j'allais suggérer Remoting! Les Notes de publication de Mono 1.0 (de archive.org parce que l'emplacement d'origine est manquant) mentionne System.Runtime.Remoting.dll comme une bibliothèque prise en charge et ne dit rien sur les problèmes connus.

Si la communication à distance est désactivée, vous devrez probablement implémenter votre propre protocole de trame de message TCP. Windows n'a pas d'équivalent des sockets du domaine UNIX pour la communication sur le même ordinateur.

Answer 7

La plupart des services ayant un composant d'interface graphique sont exécutés en tant qu'utilisateur nommé et sont autorisés à accéder au bureau. Cela vous permet d'y accéder via COM ou .NET mais uniquement localement (à moins que vous ne vouliez vous compliquer la tâche).

Personnellement, j’ouvre une vieille socket ordinaire sur le service - sa plate-forme multiplate-forme, autorise plusieurs clients, permet à n’importe quelle application d’y accéder, ne dépend pas de la sécurité Windows, et permet à votre interface graphique de fonctionner correctement. écrit dans la langue de votre choix (tout supporte les sockets).

Pour une application de type plateau, vous souhaitez qu'un protocole simple communique. Vous pouvez également utiliser un système de style REST pour lui envoyer des commandes, puis renvoyer du XML (yuk) ou un format de données personnalisé.