Question

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 dans laquelle j'aimerais m'abonner d'une manière ou d'une autre à "OnEmailSent", même de la première application.

Existe-t-il un moyen d'attacher 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 le réflecteur.

Ce que nous voulons faire, c'est que d'autres actions aient lieu lorsque ce composant envoie un e-mail.

Le moyen le plus efficace auquel nous puissions penser serait de pouvoir utiliser une certaine forme d'IPC comme l'a suggéré Anders et d'écouter l'événement OnEmailSent déclenché par le composant tiers.

Étant donné que le composant est écrit en C#, nous envisageons d'écrire une autre application C# qui puisse s'attacher au processus en cours d'exécution et lorsqu'elle détectera que l'événement OnEmailSent a été déclenché, elle exécutera son propre code de gestion des événements.


Il me manque peut-être quelque chose, mais d'après ce que je comprends du fonctionnement de la communication à distance, il faudrait un serveur définissant une sorte de contrat auquel le client peut souscrire.

Je pensais plutôt à un scénario dans lequel quelqu'un aurait écrit une application autonome comme Outlook par exemple, qui expose les événements auxquels j'aimerais m'abonner depuis une autre application.

Je suppose que le scénario auquel je pense est le débogueur .net et comment il peut s'attacher aux assemblys en cours d'exécution pour inspecter le code pendant son exécution.

Était-ce utile?

La solution

Pour que deux applications (processus distincts) échangent des événements, elles doivent s'entendre sur la manière dont ces événements sont communiqués.Il existe de nombreuses façons différentes de procéder, et la méthode exacte à utiliser peut dépendre de l'architecture et du contexte.Le terme général désignant ce type d’échange d’informations entre processus est Communication inter-processus (IPC).Il existe de nombreuses façons standard de réaliser l'IPC, les plus courantes étant les fichiers, les canaux, les sockets (réseau), appels de procédure à distance (RPC) et mémoire partagée.Sous Windows, il est également courant d'utiliser messages de la fenêtre.

Je ne sais pas comment cela fonctionne pour les applications .NET/C# sous Windows, mais dans les applications Win32 natives, vous pouvez accrochez-vous à la boucle de messages des processus externes et « espionnez » les messages qu’ils envoient.Si votre programme génère un événement de message lorsque la fonction souhaitée est appelée, cela pourrait ê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 également d'exécuter les applications sur différentes machines physiques (étant donné qu'elles sont connectées via un réseau).

Autres conseils

Tu peux essayer Espion géré et pour l'accès par programmation ManageSpyLib

ManagedSpyLib introduit une classe appelé ControlProxy.Un ControlProxy est une représentation d’un System.Windows.Forms.Control dans un autre processus.ControlProxy permet vous d’obtenir ou de définir des propriétés et Abonnez-vous aux événements comme si vous étiez Exécution à l’intérieur de la destination processus.Utiliser ManagedSpyLib pour tests d’automatisation, journalisation des événements pour compatibilité, processus croisé ou des tests en boîte blanche.

Mais cela pourrait 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 recherchez dans votre application tierce.

Vous pouvez également utiliser Réflexe

Reflexil permet modifications de l’IL à l’aide de la puissante Bibliothèque Mono.Cecil écrite par Jb EVAIN.Reflexil fonctionne en tant que plug-in Reflector et s’adresse particulièrement au code IL manutention.Pour ce faire, il Proposer une instruction complète et en autorisant le code C#/VB.NET injection.

Vous pouvez utiliser l'accès à 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 provenant de cette application tierce ?Je veux dire, comment savez-vous que l'application déclenche un tel événement ?

Si toi 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 avez vraiment besoin de communiquer entre processus, vous aurez besoin d’une sorte de mécanisme.La liste est longue, très longue.Des simples messages WM_DATA aux protocoles TCP personnalisés en passant par les services Web très complexes nécessitant des infrastructures supplémentaires.

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

En outre, le débogueur dispose d’une manière très invasive de déboguer les processus.Ne vous attendez pas à ce que ce soit le mécanisme interprocessus 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 maintenant une connexion SqlConnection persistante avec une application .NET qui bloque jusqu'à ce que les données soient modifiées dans la base de données.

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

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top