Mef and Module Dependencies in Silverlight

Topics: Prism v4 - Silverlight 4
Sep 7, 2010 at 12:40 AM

Hi, i'm new to Prism, so i'm still learning how to use it properly

i'm writing an application with a structure similar to this one:

  • Main Silverlight Client Project: it's only purpose is to download Xap files (with xaml catalog), load assemblies and manage regions. (doesn't reference any other assembly in my solution)
  • Grouped Interface Libraries: a certain number of Silverlight Class Libraries. Each group of functionalities is identified by it's own class library.
  • Grouped Implementation Libraries: for every Interface Library, there're multiple implementations, each one in it's own project and each one exported, with MEF, as interface.
  • Grouped Interface Modules: only used to download one of the Class Libraries containing a group of interfaces
  • Grouped Implementation Modules: used to download one of the Class Libraries containing an implementation. every module has a viewmodel that consume the interface implementation. every module Depends On the module containing the interface.

so, when i want to load a functionality, i've to download the interface that corresponds to that functionality and load the assembly, then i can download one of the implementations (one is enough, but i could get more of them), load it and register the view with the region manager.

as soon as i start downloading an implementation module, prism starts downloading the required interface module, because of the DependsOn parameter.

if the implementation module's download is finished before the interface's one, the application throw a ModuleTypeLoadingException, because, i think, MEF is trying to export a class that require an interface that is in an assembly that isn't already available (DependsOn only defers the call to the Module constructor and to the IModule Initialize method)

i'm not sure if this is the correct approach but i want to do is:

  •  keeping everything out of the main silverlight application
  • group funcionality by shared interfaces

here is a sample application

Sep 7, 2010 at 8:06 PM


Thanks for reporting that. There are no similar issues reported yet, so I will copy this as a work-item. This way the prism product team is notified and the community could vote this.

As for your approach, it seems to be a possible one. But the only thing that you could review if it is really necessary to create a module for the interfaces. As the interfaces assemblies are required from the functionality assemblies (you have to implement them in the concrete classes), I’m not sure if they should be decoupled. In other words, I would recommend to you the usage of strong references in this particular case.

In your sample application, there are strong references between functionality and the interfaces assemblies. So, it seems not necessary to depend on an interface module if you have CopyLocal=True on references to the interface’s assembly.

For more information you could take a look at the following quickstart of the latest drop:

  • ModularityWithMEF, you can find this at <PrismInstallationDirectory>\Quickstarts\Modularity\[Desktop|Silverlight]

Please let me know if this helps.

Fernando Antivero

Sep 7, 2010 at 8:07 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.