Where does PartInitializer get it's catalog from?

Dec 9, 2009 at 3:31 AM

I have a scenario where I am dynamically downloading and instantiating XAP files.  The problem is, when the XAP file turns up it doesn't appear to have it's Assemblies loaded into a catalog where PartInitializer is looking because 'SatisfyImports()' fails to find the corresponing Exports (they *are* in the XAP package...I've verified this by running the XAP on it's own, and MEF works fine).

 

So I'm wondering if there some global catalog that PartInitializer maintains which I can register the assemblies in as I dynamically load them (thus allowing MEF to discover them when I need the imports satisfied)?  

Thanks!

Dec 9, 2009 at 8:32 PM

You can set your own CompositionContainer which the PartInitializer will use by calling CompositionHost.InitializeContainer. Note that it does not initialize the container with the defaults catalogs as the default behavior would. The container will remain empty until you add the catalogs manually.

Dec 10, 2009 at 7:24 PM
Hi Phil
 
I will be blogging on this shortly. You need to override PartInitializer's container to do this.
 
To override you call CompositionHost.InitializeContainer() in the app and pass in your configuration. For example you might do this....
 
var catalog = new AggregateCatalog();
var packages = new PackageCatalog();
catalog.Catalogs.Add(Package.Current); //add the current xap
catalog.Catalogs.Add(packages);
var container = new CompositionContainer(catalog);
container.ComposeExportedValue<PackageCatalog>(packages);
CompositionHost.InitializeContainer(container);
 
By doing this, you will now be able to have parts import PacakageCatalog, thus they can add new packages as they show up.
 
This shows you the bare bits needed to get this work. In practice, you probably don't want to surface the catalog directly. Instead you should wrap the catalog in some sort of service that will let you add a package without directly accessing the catalog.
 
HTH
Glenn
Dec 10, 2009 at 7:57 PM
Hi Phil
I will be blogging on this shortly. You need to override PartInitializer's contianer to do this.
To override you call CompositionHost.InitializeContainer() in the app and pass in your configuration. For example you might do this....
var catalog = new AggregateCatalog();
var packages = new PackageCatalog();
catalog.Catalogs.Add(Package.Current); //add the current xap
catalog.Catalogs.Add(packages);
var container = new CompositionContainer(catalog);
container.ComposeExportedValue<PackageCatalog>(packages);
CompositionHost.InitializeContainer(container);
By doing this, you will now be able to have parts import PacakageCatalog, thus they can add new packages as they show up.
This shows you the bear bits needed to get this work. In practice, you probably don't want to surface the catalog directly. Instead you should wrap the catalog in some sort of service that will let you add a package without directly accessing the catalog.
HTH
Glenn

From: philcockfield [notifications@codeplex.com]
Sent: Thursday, December 10, 2009 11:13 AM
To: Glenn Block
Subject: Re: Where does PartInitializer get it's catalog from? [MEF:77545]

From: philcockfield

I have a scenario where I am dynamically downloading and instantiating XAP files. The problem is, when the XAP file turns up it doesn't appear to have it's Assemblies loaded into a catalog where PartInitializer is looking because 'SatisfyImports()' fails to find the corresponing Exports (they *are* in the XAP package...I've verified this by running the XAP on it's own, and MEF works fine).

So I'm wondering if there some global catalog that PartInitializer maintains which I can register the assemblies in as I dynamically load them (thus allowing MEF to discover them when I need the imports satisfied)?

Thanks!

Dec 11, 2009 at 7:40 PM

Wonderful!!  That does the trick.  Thanks Glenn and Pekkah

I can see MEF becoming a very valuable new friend indeed!


Dec 11, 2009 at 8:17 PM

Great! Looking forward to your blog post ;-)

Dec 12, 2009 at 8:40 PM
Edited Dec 12, 2009 at 8:48 PM

Glenn,

Where does that PackageCatalog come from? Is it not included in the Silverlight 4 beta bits?

 

UPDATE: Found it. It's part of the Silverlight toolkit : 

System.ComponentModel.Composition.Packaging.Toolkit.dll

http://silverlight.codeplex.com/wikipage?title=Silverlight%20Toolkit%20November%202009%20change%20list

 

Even thought MEF is in beta/preview stages the documentation should be improved a lot. Especially differences between Windows and Silverlight.

Dec 18, 2009 at 1:37 PM

Hi Pekkah,

Actually you can find those classes in some examples that are delivered accompanying with MEF Source Code.

Cheers

Steven