AppDomains allow you to save memory by unloading assemblies that are no longer being needed, and therefore lead themselves to being a good foundation for a plugin architecture.

But to communicate across boundaries, you need your classes to be MBR (MarshallableByRef)

A simple summary of why you have to watch out for not polluting the Main AppDomain when you invoke methods on assemblies in a Sandbox/plugin domain.

http://www.devsource.com/c/a/Using-VS/Dynamic-Plugins-Using-the-codeAppDomaincode-Class-to-Load-and-Unload-Code/

The how to check that you haven't inadvertently pulled in stuff you don't want (and can't unload), is by:

Using application domains right isn't all that much harder than using application domains wrong. What is awkward is that the standard deserialization behavior can "leak" code from one AppDomain to another. So, pay attention to what you return from your "isolated" AppDomain, and be sure to check AppDomain.CurrentDomain.GetAssemblies() before you sign off on your code.