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: https://msdn2.microsoft.com/en-us/library/8bxxy49h.aspx
Comments
Anonymous
January 03, 2008
The comment has been removedAnonymous
January 03, 2008
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 :)Anonymous
January 04, 2008
Hi.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?Anonymous
January 04, 2008
This sounds great. Could you post a code example on how to do this?Anonymous
January 05, 2008
Guys, I don't know if you are aware of it but all the samples download links are broken.for example:http://msdn2.microsoft.com/en-us/library/bb913903.aspxLook at my forum entry:http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2597659&SiteID=1Can you help?Anonymous
January 09, 2008
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.JackGAnonymous
January 09, 2008
We just posted a solution to consider for the F.A.Q. of how to enable isolatable WinForms applications.Anonymous
January 11, 2008
The sample download at http://msdn2.microsoft.com/en-us/library/8bxxy49h.aspx 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? :)Anonymous
January 13, 2008
The comment has been removedAnonymous
January 13, 2008
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 http://msdn2.microsoft.com/en-us/library/ instead of pointing to the file sample.Please help restoring those very important samples!You have my ThanksArielAnonymous
February 12, 2008
Jack/Jesse,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?Regards,IanAnonymous
February 13, 2008
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:http://blogs.msdn.com/clraddins/archive/2007/05/01/using-appdomain-isolation-to-detect-add-in-failures-jesse-kaplan.aspxhttp://blogs.msdn.com/clraddins/archive/2007/05/03/more-on-logging-unhandledexeptions-from-managed-add-ins-jesse-kaplan.aspxAnonymous
February 15, 2008
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?Thanks,EricAnonymous
March 30, 2008
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?Anonymous
July 17, 2008
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.Anonymous
August 25, 2008
I have this problem too, anybody know solution for this?Anonymous
November 21, 2008
Hi,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?Thanks,Kaan