If you have been working with .NET for any length of time you will already be familiar with the System.AppDomain class. The name AppDomain is short for application domain and an application domain is an artificial sub-process division that the .NET runtime provides. The idea is that a single process hosting the .NET runtime can split its memory space up into compartments that are isolated from each other.
The AppDomain class is provided as part of the .NET Framework to help manage application domains within your application. So what is there to manage? For your everyday application you would probably use the AppDomain class in much the same way as the Activator class that I covered earlier for creating instances from type strings and what have you. Where it gets really interesting however is putting dynamically loaded plug-ins into a sandbox for security and isolation purposes.
A little while ago I was building a Windows Service which needed to load a whole series of plug-ins written by other developers. The role of the plug-ins were to execute some custom logic on messages routed to them and use a set of APIs that were provided to record information in a database and push other messages back out. While it wasn’t strictly necessary to load each plug-in into its AppDomain it give us a nice side effect of allowing each plug-in developer free reign over their own configuration file, so if they just wanted to using <appSettings /> they could and we wouldn’t need to worry about merging configuration entries at deployment.
While AppDomains are good, they do carry overheads in terms of memory utilisation and even creation. But they can also be a little bit tricky to control from a lifetime point of view. It is almost always a good idea to keep a handle any application domains that you have created, and if you plan to communicate across domains you need to remember that you are essentially dealing with a distributed application which means you are bound by all the rules of .NET remoting - even though you are in the one process.
I don’t think application domain isolation is required (or even desirable) for every plug-in system, but its definately worth understanding what they are and what they can do for you.