为了使两个应用程序（单独的进程）交换事件，他们必须同意如何传达这些事件。有很多不同的方法来做，而使用哪种方法可能取决于架构和上下文。进程之间的这种信息交换的一般术语是进程间通信（IPC） 。存在许多标准的IPC方法，最常见的是文件，管道，（网络）套接字，远程过程调用（RPC）和共享内存。在Windows上，使用窗口消息也很常见。

我不知道如何在Windows上适用于.NET / C＃应用程序，但是在本机Win32应用程序中，您可以挂钩到外部进程的消息循环和间谍上他们发送的消息。如果您的程序在调用所需功能时生成消息事件，则可能是一种检测方式。

如果您自己实现这两个应用程序，您可以选择使用任何您喜欢的IPC方法。这些天，网络套接字和更高级的基于套接字的协议（如HTTP，XML-RPC和SOAP）非常受欢迎，因为它们允许您在不同的物理机上运行应用程序（因为它们通过网络连接）。 / p>

Suppose I have two applications written in C#. The first is a third party application that raises an event called "OnEmailSent".

The second is a custom app that I've written that I would like to somehow subscribe to the "OnEmailSent" even of the first application.

Is there any way that I could somehow attach the second application to an instance of the first application to listen for "OnEmailSent" event?

---

So for further clarification, my specific scenario is that we have a custom third party application written in c# that raises an "OnEmailSent" event. We can see the event exists using reflector.

What we want to do is have some other actions take place when this component sends an email.

The most efficient way we can think of would be to be able to use some form of IPC as anders has suggested and listen for the OnEmailSent event being raised by the third party component.

Because the component is written in C# we are toying with the idea of writing another C# application that can attach itself to the executing process and when it detect the OnEmailSent event has been raise it will execute it's own event handling code.

---

I might be missing something, but from what I understand of how remoting works is that there would need to be a server defining some sort of contract that the client can subscribe to.

I was more thinking about a scenario where someone has written a standalone application like outlook for example, that exposes events that I would like to subscribe to from another application.

I guess the scenario I'm thinking of is the .net debugger and how it can attach to executing assemblies to inspect the code whilst it's running.

In order for two applications (separate processes) to exchange events, they must agree on how these events are communicated. There are many different ways of doing this, and exactly which method to use may depend on architecture and context. The general term for this kind of information exchange between processes is Inter-process Communication (IPC). There exists many standard ways of doing IPC, the most common being files, pipes, (network) sockets, remote procedure calls (RPC) and shared memory. On Windows it's also common to use window messages.

I am not sure how this works for .NET/C# applications on Windows, but in native Win32 applications you can hook on to the message loop of external processes and "spy" on the messages they are sending. If your program generates a message event when the desired function is called, this could be a way to detect it.

If you are implementing both applications yourself you can chose to use any IPC method you prefer. Network sockets and higher-level socket-based protocols like HTTP, XML-RPC and SOAP are very popular these days, as they allow you do run the applications on different physical machines as well (given that they are connected via a network).