Communication between AppDomains

问题:

We are building an app (WinForms, .NET 3.5) that loads "Plugin" DLLs into a secondary AppDomain. The secondary AppDomain needs to communicate occasionally with the 1st one (more specifically, call or get data from objects that are created in the main AppDomain).

I have read most of the material about AppDomains and communication between them.

So far, the only easy solution i've seen was inheriting from MarshalByRefObject and passing a TransparentProxy into the 2nd AppDomain, calling methods on the Proxy.

This method has its drawbacks (not always possible to inherit from MBRO in case of framework types for example, or types that already inherit from another class, static fields/classes and so on).

Since the current communication points are pretty constant (only 2-3 scenarios that require communication), i have considered creating a simple Mediator class with the following properties:

1. Will be created in the 1st (Main) AppDomain.
2. Would function only as a "message-passer" to the "Real" objects that are created in the main AppDomain.
3. Will inherit from MBRO, and a proxy reference to it will be sent to the 2nd AppDomain.

Methods on this proxy object would be called, which in turn will call the methods on the "real" objects in the 1st AppDomain.

My questions --

1. Does this seem like a logical design?
2. More importantly, does a mediator/message passer class already exist in WCF or any other communcation framework? it seems like a generic concept and i am wondering if there is something similar.

回答1:

Unless you specifically want to avoid WCF for some reason, I would suggest taking a look at it. Specifically, you can use the NetNamedPipeBinding, which provides for communication on the same machine using named pipes. You can find some more information here: http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx

As well, here is a reasonably concise blog entry demonstrating it's use (from a WMP plug-in to a third-party app).

Based on your description of the application, you could establish a WCF service in the first AppDomain then call into that service from the second AppDomain.