Sanity Check – Multiple appdomains in a winforms app?


Hi guys - here is yet another question for you to ponder 🙂


Has anyone ever come across an reasonably architectured winforms system which used multiple appdomains?  We chose to do so, and now I am getting burned by the ugly hacks needed to get the thing working - configuring remoting between the domains (in the same app for christ sake!) , borked singletons,  hauling around the EnterpriseServices call context, etc.


I would like to hear your thoughts on this this...  Is this a reasonable architecture or is ir plain FUBAR ?  Any gotchas I can use to argue my case?


 


 


Comments (3)
  1. I’ve heard horror stories about performance, too, for multi-appdomain WinForms apps.

    What was the original motivation for multiple appdomains?

    The only good reason I’ve found for explicitly spawning a separate appdomain is to control the lifetime of dynamically loaded/generated code — because the CLR does not GC code.

    Examples include apps that use RegexOptions.Compiled, on user-entered regular expressions… or apps that execute user-written "scripts" via the CodeDom compilers… or apps that load a large number of plugin assemblies, but which are only needed for a limited time.

    In any case, I’d take great care when designing the interfaces between the two appdomains — almost as if I were architecting a DCOM system — and certainly not try to do UI in anything but the primary domain.

    -S

  2. Martin Naughton says:

    NUnitGui uses multiple AppDomains. It loads the Test Fixture assembly into a secondary AppDomain. I believe the motivation is to allow the Test Fixture assembly to be unloaded from memory, without restarting the NUnitGui application.

    If you may need to unload an assembly during a UI session, multiple AppDomains are required, as far as I know.

    Martin

  3. How windows forms works with app domain has changed between 1.0 and 1.1. In 1.0 you could have one primary form per app domain. In 1.1 you can only have one per process.

    One way to avoid remoting between app domains in the same process is to use COM. You can pass a COM object between domains as an IntPtr. I’ve sucessfuly used this technique to make pass the DTE object to a new app domain in the VS.NET process. I wonder if it is possible to do the same thing with Windows Forms controls? I suspect it is (certainly if you register them as COM/ActiveX objects)…

    http://dotnetweblogs.com/nunitaddin/posts/6066.aspx

Comments are closed.

Skip to main content