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
var container = new CompositionContainer(catalog);
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.
From: philcockfield [email@example.com]
Sent: Thursday, December 10, 2009 11:13 AM
To: Glenn Block
Subject: Re: Where does PartInitializer get it's catalog from? [MEF:77545]
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)?