In the following scenario there appears to be an issue with recomposition.
Let's say I have an app with two XAP files, Main.XAP and Extensions.XAP. Main.XAP has a Class which has a property named "Widgets" (As IWidget) marked with ImportMany(AllowRecomposition:=True). Extensions.XAP is downloaded via the Aggregate/Deployment
catalog method and SatisfyImports is called, which populates my property with a collection of IWidget values exported in Extensions.XAP, one of these is "ClockWidget" defined in Extensions.XAP.
Next, I go and modify Extensions.XAP adding a new TextBlock to my "ClockWidget" XAML, which implements IWidget (InheritedExport) and I recompile it. A directory polling service notices that Extensions.XAP has been modified and proceeds to
remove it from the AggregateCatalog on the client, which triggers a recomposition that clears the "Widgets" property. Then it adds the new version of Extensions.XAP triggering another recomposition, which fills in the "Widgets" property
with IWidget implementations (including "ClockWidget") again.
Now, my problem is that when "Widgets" is filled in after Extensions.XAP is updated, the widgets still reflect the
old version of Extensions.XAP before it was recompiled/redeployed. The new TextBlock that was added to "ClockWidget" does not appear on the UI. If I close the application and re-open without recompiling anything, "ClockWidget"
has the new TextBlock.
It would seem that somehow MEF or Silverlight caches the old version of the "ClockWidget" part or the assembly it was a part of and re-uses that when it composes it the second time. The CompositionContainer and Deployment.Current.Parts both
seem to have the correct values through points in the workflow.
Any ideas why the old version of "ClockWidget" would be used instead of the new version? Is there any way to prevent MEF or Silverlight from caching the old Part/Assembly, or a way to unload it before recomposition is done?
There appears to be an issue when using XAP Partitioning and recomposition.