views:

459

answers:

2

I have a WPF app which contains a number of child controls.

One of these controls hosts a third party library which underneath the covers runs some native code which throws access violations and crashes the application. Unfortunately removing the library is not an option.

What I'd like to do is spin up a new windows process, host the third party library inside that, and somehow communicate with it. Much in the same way that Google Chrome and IE8 handle browser plugins.

The issue is that the third party library needs to draw to the screen, so I have to somehow have the equivalent of an HTML iframe inside my WPF app's main window.

I'm not sure how to get started on this, it's proving difficult to google for thus far. Any advice is greatly appreciated.

Thanks

A: 

Probably not the easiest of tasks. Have you considered hosting your 3rd party stuff in a separate App-Domain? That way you will also get a good level of isolation while saving you the hassle of another project. Does it have to be refreshed constantly or could you refresh at predefined points in your application? Maybe some scheme where you basically do a screenshot of the 3rd party output and show it as image in your original app would then be possible...

flq
As I understand it a seperate AppDomain still lives within the same win32 process? I need to run it in a seperate windows process because the 3rd party application is crashing at the native code level (win32 access violations and so-forth). When these happen, the entire windows process goes down, .NET and all
Orion Edwards
An AppDomain should do the trick for you - if one AppDomain goes down, the others are fine. Think of an AppDomain as a ".NET process" (sort of).
Andy
You'd have to bring the control across the boundary for this to work, and controls don't extend MarshallByRefObject. So this won't work.
Will
If it won't work, how does System.Addin in the BCL do it? They have demos of WPF usercontrols running out-of-process
Orion Edwards
Just to clarify - AppDomains only give memory isolation, they do no protect the application at an execution level. This means that if ANY AppDomain within the process, experiences an Unhandled Exception, it will take the entire process down. The only way to protect the hosting application is to ensure that unsafe code is isolated in a separate process.
Adam
+1  A: 

This is a tough one, but fortunately for you there is a little work being done in this space lately.

Have you heard of the System.Addin namespace in .NET 3.5? It could probably help in this case. It allows for controls to be loaded in a separate AppDomain, but be displayed in the same UI. I'd imagine you'd have to do a little bit of work to get everything communicating properly (never done this before), but it's possible.

Have a look at this early post from the Add-in team: http://blogs.msdn.com/clraddins/archive/2007/08/06/appdomain-isolated-wpf-add-ins-jesse-kaplan.aspx

Seems like they keep their samples and helper code on codeplex: http://clraddins.codeplex.com/

I'm very interested in this, so if you get this working, let us know how this went for you!

Anderson Imes
Thanks.I've investigated System.Addins before and it looks like it should work. I'll download the clr-addins sample and have a look.Hopefully I'll be able to figure out the underlying technique they are using and use it on my own - the contract stuff required by System.Addins is much more heavyweight than what I need or want.
Orion Edwards
The way I read it they are doing a lot or you there. Unless you need a lot to be dynamic, take a look at the "pipeline generator"... Hopefully that will get you started and maybe be able to ignore a lot of the contract stuff. They are doing some pretty crazy magic there. I could have read wrong but it looks like they have support for out of process... Which would be crazy hard to implement.
Anderson Imes