Resolving service interface type via deployment catalog

Topics: Prism v4 - Silverlight 4
Jan 10, 2011 at 8:43 PM


I'd like to be able to resolve service interface type provided by remote modules via xml deployment catalog with Mef. This is a different scenario than the StockTrader RI example that does it via AggregateCatalog. 

I have Shared.cs defines

public interface IService{



and a service implementation done at Service.cs


public class ModuleInit:IModule





public class Service:IService



I want to access the service via Shell(), so I did

public partial class Shell :UserControl



public IService sv;


and also add a reference to the Shared assembly in main silverlight project.

Running code like that always produces a runtime error complaining "No valid exports were found..." What goes wrong with my approach? If I put things back to AggregateCatalog by commenting the XML and add the Service assembly reference back to the project. Everything work! We'd like to have a decoupled architecture so the application could access different service implementation by just update ModuleCatalog.xml in website without rebuilding the app. How could this be done in Prism?

Basically I'd like to access my own remote service in Shell like accessing IModuleManager in Prism library but without explicitly loading the implementation via code. This example at fits the bill except accessing the service from Shell(), and it produces the same error when I tried to modify it...



Jan 11, 2011 at 6:14 PM

Hi Reggie,

Perhaps the problem you're experiencing could be caused by a timing issue. That is to say, when you load a module using the DeploymentCatalog, its catalog is added to the AggregateCatalog in the same way as it is done when you directly add the AssemblyCatalog to the AggregateCatalog in code. The difference is that in the second case, at the time the shell is composed (which is done by default in the CreateShell or InitializeShell methods of the Bootstrapper), your module that provides the implementation for IService might not have been loaded yet, hence causing that exception.

You can read more about remote module loading here, and about the initialization sequence of Prism applications here.

I hope you find this helpful.

Guido Leandro Maliandi