Écouter les événements dans une autre application

Supposons que j’ai deux applications écrites en C #. La première est une application tierce qui déclenche un événement appelé “OnEmailSent”.

La seconde est une application personnalisée que j’ai écrite et que je voudrais en quelque sorte souscrire au “OnEmailSent” même de la première application.

Existe-t-il un moyen de relier la deuxième application à une instance de la première application pour écouter l’événement “OnEmailSent”?

Donc, pour plus de précisions, mon scénario spécifique est que nous avons une application tierce personnalisée écrite en c # qui déclenche un événement “OnEmailSent”. Nous pouvons voir que l’événement existe en utilisant un réflecteur.

Ce que nous voulons faire, c’est que d’autres actions soient effectuées lorsque ce composant envoie un courrier électronique.

Le moyen le plus efficace auquel nous puissions penser serait de pouvoir utiliser une forme quelconque d’IPC comme l’a suggéré anders et d’écouter l’événement OnEmailSent généré par le composant tiers.

Comme le composant est écrit en C #, nous envisageons d’écrire une autre application C # pouvant se rattacher au processus en cours d’exécution. Lorsqu’il détecte que l’événement OnEmailSent a été déclenché, il exécute son propre code de gestion d’événements.

Il se peut que je manque quelque chose, mais d’après ce que j’ai compris de la façon dont fonctionne le transfert à distance, il faudrait un serveur définissant un type de contrat auquel le client peut souscrire.

Je pensais plutôt à un scénario dans lequel une personne a écrit une application autonome, telle que Outlook par exemple, qui expose les événements auxquels je souhaite m’abonner à partir d’une autre application.

Je pense que le scénario auquel je pense est celui du débogueur .net et de la manière dont il peut être associé à l’exécution d’assemblys pour inspecter le code pendant son exécution.

Pour que deux applications (processus distincts) puissent échanger des événements, elles doivent s’accorder sur la manière dont ces événements sont communiqués. Il existe de nombreuses façons de le faire et la méthode à utiliser dépend de l’architecture et du contexte. Le terme général pour ce type d’échange d’informations entre processus est la communication inter-processus (IPC) . Il existe de nombreuses méthodes standard pour effectuer l’IPC, les plus courantes étant les fichiers, les pipes, les sockets (réseau), les appels de procédure distante (RPC) et la mémoire partagée. Sous Windows, il est également courant d’utiliser des messages de fenêtre .

Je ne suis pas sûr de savoir comment cela fonctionne pour les applications .NET / C # sous Windows, mais dans les applications Win32 natives, vous pouvez vous connecter à la boucle de messages des processus externes et “espionner” les messages qu’elles envoient . Si votre programme génère un événement de message lorsque la fonction souhaitée est appelée, cela peut être un moyen de le détecter.

Si vous implémentez vous-même les deux applications, vous pouvez choisir d’utiliser la méthode IPC de votre choix. Les sockets réseau et les protocoles basés sur des sockets de niveau supérieur tels que HTTP, XML-RPC et SOAP sont très populaires de nos jours, car ils vous permettent d’exécuter les applications sur différentes machines physiques (étant donné qu’elles sont connectées via un réseau).

Vous pouvez essayer Managed Spy et pour un access par programme ManagedSpyLib

ManagedSpyLib introduit une classe appelée ControlProxy. Un ControlProxy est une représentation d’un System.Windows.Forms.Control dans un autre processus. ControlProxy vous permet d’obtenir ou de définir des propriétés et de vous abonner à des événements comme si vous vous exécutiez dans le processus de destination. Utilisez ManagedSpyLib pour les tests d’automatisation, la consignation d’événements pour la compatibilité, la communication inter-processus ou les tests de whitebox.

Mais cela peut ne pas fonctionner pour vous, cela dépend si ControlProxy peut accéder d’une manière ou d’une autre à l’événement que vous souhaitez dans votre application tierce.

Vous pouvez également utiliser Reflexil

Reflexil permet les modifications IL en utilisant la puissante bibliothèque Mono.Cecil écrite par Jb EVAIN. Reflexil fonctionne comme un plug-in Reflector et s’adresse en particulier à la gestion du code IL. Pour ce faire, il propose un éditeur d’instructions complet et autorise l’injection de code C # / VB.NET.

Vous pouvez utiliser la communication à distance ou WCF. Voir http://msdn.microsoft.com/en-us/library/aa730857(VS.80).aspx#netremotewcf_topic7 .

Quelle est la nature de cet événement OnEmailSent à partir de cette application tierce? Je veux dire, comment savez-vous que l’application déclenche un tel événement?

Si vous envisagez de faire de la communication interprocessus, la première question que vous devriez vous poser est la suivante: est-ce vraiment nécessaire?

Sans remettre en question vos motivations, si vous devez réellement établir une communication interprocessus, vous aurez besoin d’un mécanisme. La liste est longue, très longue. Des simples messages WM_DATA aux protocoles TCP personnalisés aux services Web très complexes nécessitant des infrastructures supplémentaires.

Cela amène la question, qu’est-ce que vous essayez de faire exactement? Quelle est cette application tierce sur laquelle vous n’avez aucun contrôle?

En outre, le débogueur a une méthode très invasive de processus de débogage. Ne vous attendez pas à ce que ce soit le mécanisme interprocess standard utilisé par toutes les autres applications. En fait, ce n’est pas le cas.

Vous pouvez implémenter un scénario similaire avec les notifications de modification de requête SQL Server 2005 en conservant une connexion SqlConnection persistante avec une application .NET qui bloque jusqu’à ce que les données soient modifiées dans la firebase database.

Voir http://www.code-magazine.com/article.aspx?quickid=0605061 .