Iirr system.addin namespace lets you load add-ins in their own appdomain in WPF.
Sent from my phone On 12/10/2011, at 5:43 PM, Patrick Klug <[email protected]> wrote: > AFAIK there is no direct support for this. Controls still need to be all in > the same app domain. > > There might be some workaround that allows you to host a separate window > inside another window but you probably still need to have the same appdomain. > > cheers, > Patrick > > > On Wed, Oct 12, 2011 at 4:31 PM, Greg Keogh <[email protected]> wrote: > Folks, I’m writing an app that has controls as plug-ins. I’m following a > typical pattern by creating an SDK project with all the interfaces and helper > classes shared by the shell and the plug-in projects. The shell and the > plug-ins only know of each other via interfaces. > > > > I’m wondering how technically far I can take the plug-in pattern at runtime > with WPF. In WinForms and WPF you can call Assembly.LoadFrom over DLL files, > find classes that contain plug-in controls, instantiate them and add them to > a parent control. I’ve done this lots of times and all of the loaded classes > and assemblies go into the main AppDomain. > > > > Is there a technique in the WPF world that allows me to find and load > controls and place them in their own AppDomains so they are well separated at > runtime? You can’t do this with WinForms controls. I’m just curious if there > are new snazzy techniques in WPF for this sort of thing. > > > > Cheers, > > Greg > > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf > > > _______________________________________________ > ozwpf mailing list > [email protected] > http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
_______________________________________________ ozwpf mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozwpf
