Langage C#
  1. Langage C#
  3. Comment communiquer avec un service Windows à partir d’une application qui interagit avec le bureau?
Intereting Posts
Comment vous débarrassez-vous de IDisposableobject create à l’intérieur d’une expression Linq? Devrais-je créer une nouvelle instance de délégué? Conventions de nommage en C # – soulignés Les tables de jointure dans SQLite.Net avec LINQ sur xamarin.android ne sont pas sockets en charge. La conversion d’un type de données datetime2 en un type de données datetime a entraîné une valeur hors limites. comment sortinger une collection par date / heure en c # ‘Modèle’ est en conflit avec la déclaration ‘System.Web.Mvc.WebViewPage .Model WPF DispatcherFrame magic – comment et pourquoi cela fonctionne? Se moquer des nouveaux Microsoft Entity Framework Identity UserManager et RoleManager Service WCF, authentification Windows Remplacement de la DLL par une version plus récente Hangfire.Autofac avec application MVC – échec de l’injection Retourne une collection vide quand Linq ne retourne rien Comment puis-je append un nœud racine personnalisé lors de la sérialisation d’un object avec JSON.NET? Pourquoi NHibernate lance-t-il «StaleObjectStateException»?

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

Avec .Net, quel est le meilleur moyen d’interagir avec un service (c’est-à-dire 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:

Oubli de mentionner, nous devons toujours prendre en charge les machines Windows 2000 sur le terrain, de sorte que WCF et tout ce qui est supérieur à .Net 2.0 ne volera pas.

Sachez que si vous envisagez de déployer éventuellement sur Windows Vista ou Windows Server 2008, cela ne fonctionnera pas de nombreuses façons aujourd’hui. 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 rest 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, Named Pipes, etc. N’utilisez pas SendMessage / PostMessage, car cela échouer sous Session 0 Isolation.

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

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

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 (Cisortingx, Remote Desktop) et que chaque utilisateur lance un “service” d’application de plateau, vous pouvez vous retrouver dans une situation où plusieurs processus essaient d’utiliser le même port ou le même canal 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.

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

C’est simple et c’est complètement cross plate-forme.

L’un de vous a-t-il 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 suffit de tester votre application pour la communication à distance multiplate-forme (MS.Net <-> Mono) de temps en temps afin d’attraper les problèmes éventuels. Et commençons par un Mono récent, 2.4.2 est à jour.

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

Curieusement, j’allais suggérer Remoting! Les notes de publication de Mono 1.0 (de archive.org, car l’emplacement d’origine est manquant) mentionnent System.Runtime.Remoting.dll comme une bibliothèque prise en charge et ne disent rien sur les problèmes connus.

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

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 (sauf si vous voulez vous compliquer la tâche)

Personnellement, j’ouvre une vieille socket ordinaire du service – sa plate-forme multiplate-forme, autorise plusieurs clients, toute application à y accéder, ne repose pas sur la sécurité Windows, et permet à votre interface graphique langue que vous aimez (comme tout supporte les sockets).

Pour une application de 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é.