MVVM Caliburn and Plugin support

Topics: UI Architecture
Feb 6, 2012 at 7:36 PM

I am in an investigation phase of a project which needs to support independent deployment of plugins.
The host and also the plug-ins should use Caliburn MVVM/MEF to get constructed.  
The plug-ins can deliver View and ViewModels and they use a common UI control library. Each plugin 
can use a different version of the common UI library.

So far my requirement which I guess are very common in our industry.

My questions are -

  1. Can somebody point me to good example to archive that goal in a elegant and consistent way.
  2. How should the plugin communicate with the host.
  3. How should the host find and construct the plugins viewmodels and views
  4. Should the plugin provide its own version of caliburn and MEF also or use the hosts version? 

Thx a lot, Joe

 

 

 

Coordinator
Feb 6, 2012 at 9:12 PM

Strictly speaking...I don't think what you are trying to do is actually possible in .NET...at least not with a single AppDomain. Within an AppDomain you cannot have multiple versions of the same assembly loaded. I do believe you can do this with separate AppDomains...but it's extremely difficult when you start talking about code running in different AppDomains sharing space in the same top level window. This is partially what the MAF (not MEF) was designed to help do, but I've never built an app with it and have never heard of anyone who has ;(  You might want to consider if you can accomplish your scenario some other way...because what you are proposing is going to be very, very difficult.

Feb 6, 2012 at 10:08 PM

Hi Rob,
I am not sure if that is really true, or at least not true anymore.
From MSDN:

http://msdn.microsoft.com/en-us/library/system.appdomain.assemblyresolve.aspx

 Beginning with the .NET Framework version 4, the ResolveEventArgs.RequestingAssembly property returns the assembly that requested the assembly load that could not be resolved. For example, the loader might be unable to load a dependency of the requesting assembly because the requesting assembly and its dependency are not in the probing path. Knowing the identity of the requesting assembly might be useful in locating the dependency or in identifying the correct version, if more than one version of the dependency is available. For more information, see ResolveEventArgs.RequestingAssembly.

Regards, Joe