Support for Windows Forms in Hosts and Add-Ins

We’ve been receiving a lot of questions recently regarding the support for Windows Forms based add-ins and hosts in a multi-AppDomain environment. Now that we’ve released .NetFX 3.5 with the support for passing WPF controls across AppDomains the lack of direct support from Windows Forms becomes more noticiable.

The good news is that it’s actually possible to use Windows Forms controls in both your hosts and add-ins and have them contribute directly to each others UI. The bad news is that Windows Forms, currently, doesn’t have any dirrect support for this feature and so you’ll have to go through WPF to do this.

In 3.5 the WPF team created the helper functions, in the System.AddIn.Pipeline.FrameworkElementAdapters class, which will convert to/from FrameworkElements and InativeHandleContract. It does this by wrapping the FrameworkElements in an HWND on one side and then parenting this HWND to a FrameworkElement on the other. This means that in actuality the FramworkElement and its children never actually get passed across the bounary.

If, in addition to the FrameworkElementAdapters class, you use the WindowsFormsHost and ElementHost classes to host WindowsForms controls in WPF elements and vice-versa then both your hosts and your add-ins can use WindowsForms controls and you can logically pass them across the AppDomain boundary without actually doing so. The downside to this approach is that this requires that you load WPF into your process. If you already have some WPF code running in your process then WPF requirment is very minimal, but it can be significant overhead in the case of a pure WindowsForms host with pure WindowsForms add-ins and you’ll have to decide for yourself whether it is worth it.

There were also a few lingering questions about whether the above technique was even supported by the WindowsForms teams but there is good news there. We were recently able to clarify this question and the answer is that it is supported because it manages to avoid actually passing across and WindowsForms controls across the AppDomain boundaries:



Comments (17)
  1. Gordon Watts says:

    I have been using this technique for a while now – it works just fine. I was amazed when I first tried it that "it just worked".

    The only difficulty I’ve had has to do with general performance — but that isn’t unique to WinForms.

    At any rate, if anyone is wondering, just stick your WinForms control in a WPF win form hosting control and you are off to the races.

  2. Miral says:

    It should actually be theoretically possible to do this with pure WinForms (well, WinForms plus p/invoke) by similarly creating a Control that can contain raw HWNDs on one side and a Control that can have a raw HWND as a parent on the other side.  It’s more work, of course, until someone publishes the necessary glue classes 😉

    I briefly looked into doing this a couple of years ago with my own custom plugin implementation, but didn’t get too far before realising that I didn’t really need it anyway 🙂

  3. Evor says:


    I’m gonna implement plugins for my WinForms application. Plugins will contains GUI. I wanna have ability to write GUI for plugin with WinForms, WPF and maybe GTK#. Which is the best way to do it with .NET 3.5?

  4. Marlun says:

    This sounds great. Could you post a code example on how to do this?

  5. Ariel says:

    Guys, I don’t know if you are aware of it but all the samples download links are broken.

    for example:

    Look at my forum entry:

    Can you help?

  6. Ariel – The link worked for me.

    Gordon – Regarding perf.  Have you tried attributing your main method with [LoaderOptimization(MultiDomainHost)]? This will help with enabling WPF images to be shared accross AppDomains.


  7. We just posted a solution to consider for the F.A.Q. of how to enable isolatable WinForms applications.

  8. Marlun says:

    The sample download at doesn’t work for me neither. Also, maybe it is me but I can’t find the F.A.Q you are talking about Jack? 🙂

  9. noslenytram says:

    I posted a straight-forward example solution for integrating Windows Controls using CLR Add-ins.

    This example uses VS2005 and, other than the add-in pipeline itself, it is, from the perspective of the host and add-in developer, a pure Windows Forms experience.

    — Marty Nelson

  10. Ariel says:

    Hi Jack,

    Thanks for the reply, but I think you missed my point.

    The link to this page works, but if you scroll into it, the Download Sample link is pointing at the general instead of pointing to the file sample.

    Please help restoring those very important samples!

    You have my Thanks


  11. Ian Duncanson says:


    Just reading the MSDN documentation on WPF add-ins, it says –

    "Due to limitations with application domains, unhandled exceptions that are thrown in add-in application domains cause the entire application to crash, even though the isolation boundary exists. However, WPF and the .NET Framework add-in model provide a simple way to work around this problem and improve application stability. A WPF add-in that displays a UI creates a Dispatcher for the thread that the application domain runs on, if the host application is a WPF application. You can detect all unhandled exceptions that occur in the application domain by handling the UnhandledException event of the WPF add-in’s Dispatcher. You can get the Dispatcher from the CurrentDispatcher property."

    I have not however been able to get this to work? Is the documentation incorrect, or if it is correct, is there a sample you have showing this capability?



  12. Garry Trinder says:

    I’m not sure there is enough detail in the WPF docs to make this easy to implement.

    There are a few blog articles that include full samples (and explanations for how/why they work) that should be helpful for you:

  13. Eric Brand says:

    Does someone have an example of a MDI parent host loading add-ins at runtime that show MDI children UI? My understanding is that forms (not user controls) can be utilized in the new System.AddIn framework but only via WPF. Does anyone have an easy-to-follow example of this in action?



  14. Luo Cao says:

    I have used this technical now. It worked, but with problems: how to change the size of ElementHost to size of the WindowsForms control which will be hosted? Can anyone help?

  15. If you want to use WinForms without having the overhead of WPF there is actually a third option.

    Create an addin that will serve as the main application hosting your MDI form or whatever. When activating addins with user controls, make sure to activate them in the same appdomain as the main addin. This way, remoting of Control classes is avoided completely.

    The downside here of course is that we loose appdomain isolation between the main gui and addin gui. The good thing is that we keep isolation between GUI stuff and the host process and also gain some performance with not having to remote between UI elements.

    I have successfully used this technique and will, when time permits, write an article about it.

  16. Nuclear says:

    I have this problem too, anybody know solution for this?

  17. Kaan Özgen says:


    I’m recently trying to build a PowerPoint COM Add-In which can support our activities at Porsche.

    I’m able -based on available samples on the internet- to create a button on the standard bar and trigger my form to show up. Though this is just the beginning and I’m already stuck.

    What I need to do is database (Access or XML) connections and based on the data gathered, add task boxes to the slide.

    Are there any samples which would guide me?



Comments are closed.

Skip to main content