I've got an application that needs to have multiple app domains to isolate potentially unsafe modules, and also provide a level of isolation for non-thread-safe code. Each module implements a common interface but will also include long-lived method calls (minutes).
In the distant past, when I did something similar, I used MarshalByRefObject but I've since read that WCF is now the preferred mechanism for communicating across the AppDomain boundary.
Since I want multiple app domains and each request may be long-lived, I see a couple of issues:
I'd initially planned to make the calls into the AppDomain asynchronous and have some form of queueing system internally that allowed me to monitor/retrieve results but in light of using WCF and the hassle of overriding enough to control instantiation of the service host object (to allow subsequent calls to be made to the same object), I'm starting to wonder if I should make all the calls blocking and allow the parent process to handle all the thread problems. of course, then I'd also need to make sure I've never got more than 1 call pending to a given app domain and perform queueing in the parent process.
Does anyone have any experience with a similar scenario/advice on a good architecture/link to a decent article?
The WCF framework is great for writing service oriented applications using a message exchange pattern through a remote procedure call mechanism. The netNamedPipesBinding could be used to achieve "management" of separate AppDomains within the same physical memory space but that level of control is not what WCF was intended for.
Maybe something along the lines of this blog post from Jeffery Richter is better suited to what you are trying to do.