Share via

Limitations of Multiple AppDomains in WPF and The Challenges of Creating a Plug-in Architecture

  • Article

AppDomains

In doing some recent prototype work, the fact that WPF does not support multiple AppDomains came up.  For most people, this is not an issue, but for certain scenarios, it causes some design challenges. The most common scenario for multiple AppDomains is when creating a plug-in model for your application and loading the plug-ins in a seperate app domain with partial trust. (See this MSDN article for a good discussion of .NET plug-in architecure as applied to WinForms and this article on AppDomains in general.) There are other scenarios as well where you might desire to isolate areas of the application that may be less stable or less mission critical through the use of multiple AppDomains. 

I don't believe this is well documented in the SDK so I thought I'd take some time to explicate what does and doesn't work in WPF as well as some work arounds.

To reiterate, WPF does not support running UI in anything other than the default full trust AppDomain (for standalone apps) or in a partial trust AppDomain (for browser-hosted XBAP scenarios). If you attempt to do this, it may "sort of" work for you and you may get away with it, which may lead you to think it is supported.  It isn't and things may start to break on you unexpectedly, especially when it comes to data-binding and resource loading.

So, what can you do?

If you require another AppDomain but you don't require partial trust (e.g. the code loaded into the second AppDomain is trusted) , you can either run multiple WPF applications in AppDomains serially or in parallel (each with its own thread). You can make new AppDomains, unload them, and communicate between them using your own MarshalByRefObjects via .NET remoting or using WCF and the NetNamedPipes binding. However, you can't mix UI elements in the same window within the same visual/logical tree. 

If you do require partial trust (e.g., your plug-ins are untrusted), your options are more limited. Running a full trust window with an additional partial trust AppDomain can cause the window to start throwing security exceptions. If partial trust is important to you, then your best bet at this point is to use frames, and navigate them to XBAPs or loose XAML (the SandboxExternalContent flag must be true for loose XAML).

I'll try to put some samples together illustrating some of these concepts.  (Thanks to Dave Relyea for help here.)

Comments

  • Anonymous
    July 04, 2007
    How to create and work with applications in AppDomains