MEF Re-Composition Question, Using XAP Partitioning With Shared References

May 17, 2010 at 5:22 PM

Hey guys,

Let me first say that I really love what MEF allows me to accomplish in my apps.  You get major props in my book!

My question is about composition.  I have a Silverlight app using XAP partitioning.  For the sake of example let's say I have the XAPs below with both XAPs referencing the same CommonObjects.dll.  Then I run my app and load up both XAP files.  The Extensions.XAP satisfies a recomposable import on one of my objects in SilverlightProject1. 

Next I make some updates to Extensions.dll and CommonObjects.dll on the server and redeploy Extensions.XAP.  When Extensions.XAP is re-deployed that change is persisted to the CompositionContainer via an AggregateCatalog filled with DeploymentCatalogs.  Imports that support recomposition are now recomposed.

At this point my app has two conflicting versions of CommonObjects.dll.  One was deployed with SilverlightProject1.XAP (and Extensions.XAP the first time), and the second was deployed with Extensions.XAP the second time it was deployed.  Which version of CommonObjects.dll gets used when the Import is recomposed?

Could you explain a bit about how XAP partitioning works with muliple XAPs containing the same assembly?

Sample app:

SilverlightProject1.XAP
    SilverlightProject1.dll
    Contracts.dll
    CommonObjects.dll

Extensions.XAP
    Extensions.dll
    Contracts.dll
    CommonObjects.dll

Looking forward to your answer.

Thanks,

-Nick

May 17, 2010 at 5:31 PM
Hi Nick

In order to have a common dll shared across XAPs the best approach is to have your main app reference the common dll, and then have each separate XAP reference's CopyLocal setting to false. With this set, the common dll will not be embedded in each of the xaps.

Sent from my IPad.

On May 17, 2010, at 9:23 AM, "1quicknick" <notifications@codeplex.com> wrote:

From: 1quicknick

Hey guys,

Let me first say that I really love what MEF allows me to accomplish in my apps. You get major props in my book!

My question is about composition. I have a Silverlight app using XAP partitioning. For the sake of example let's say I have the XAPs below with both XAPs referencing the same CommonObjects.dll. Then I run my app and load up both XAP files. The Extensions.XAP satisfies a recomposable import on one of my objects in SilverlightProject1.

Next I make some updates to Extensions.dll and CommonObjects.dll on the server and redeploy Extensions.XAP. When Extensions.XAP is re-deployed that change is persisted to the CompositionContainer via an AggregateCatalog filled with DeploymentCatalogs. Imports that support recomposition are now recomposed.

At this point my app has two conflicting versions of CommonObjects.dll. One was deployed with SilverlightProject1.XAP (and Extensions.XAP the first time), and the second was deployed with Extensions.XAP the second time it was deployed. Which version of CommonObjects.dll gets used when the Import is recomposed?

Could you explain a bit about how XAP partitioning works with muliple XAPs containing the same assembly?

Sample app:

SilverlightProject1.XAP
SilverlightProject1.dll
Contracts.dll
CommonObjects.dll

Extensions.XAP
Extensions.dll
Contracts.dll
CommonObjects.dll

Looking forward to your answer.

Thanks,

-Nick

May 17, 2010 at 5:35 PM
In terms of which dll will be used, it depends on load order. Silverlight will only load the dll once. Any additional versions will be ignored. However you don't want to pay the repeated cost of downloading the shared dll over and over, also if there are parts in the common dll it will cause duplicates to be discovered. Thus the CopyLocal solution is best.

Sent from my IPad.

On May 17, 2010, at 9:23 AM, "1quicknick" <notifications@codeplex.com> wrote:

From: 1quicknick

Hey guys,

Let me first say that I really love what MEF allows me to accomplish in my apps. You get major props in my book!

My question is about composition. I have a Silverlight app using XAP partitioning. For the sake of example let's say I have the XAPs below with both XAPs referencing the same CommonObjects.dll. Then I run my app and load up both XAP files. The Extensions.XAP satisfies a recomposable import on one of my objects in SilverlightProject1.

Next I make some updates to Extensions.dll and CommonObjects.dll on the server and redeploy Extensions.XAP. When Extensions.XAP is re-deployed that change is persisted to the CompositionContainer via an AggregateCatalog filled with DeploymentCatalogs. Imports that support recomposition are now recomposed.

At this point my app has two conflicting versions of CommonObjects.dll. One was deployed with SilverlightProject1.XAP (and Extensions.XAP the first time), and the second was deployed with Extensions.XAP the second time it was deployed. Which version of CommonObjects.dll gets used when the Import is recomposed?

Could you explain a bit about how XAP partitioning works with muliple XAPs containing the same assembly?

Sample app:

SilverlightProject1.XAP
SilverlightProject1.dll
Contracts.dll
CommonObjects.dll

Extensions.XAP
Extensions.dll
Contracts.dll
CommonObjects.dll

Looking forward to your answer.

Thanks,

-Nick

May 17, 2010 at 5:51 PM

Great, that's what I needed to know.  I'll turn Copy Local off.

May 17, 2010 at 5:51 PM

Thanks for the quick response!

Jun 14, 2010 at 9:40 AM

What is the solution if my core application (hosting the extensions) doesn't include the assembly with conflicting versions?

For example I deploy the core app which during its lifetime loads extensions from xaps uploaded to the server.
The extensions use Silverlight Toolkit assemlbies. At one point of time a new release of the toolkit comes out, and the newer extensions will be relying on the newer version.
If this happens the older or the newer extensions are going to crash depending on their load order.

Is there a technological solution or best practice for this situation?
It is hard or next to impossible to maintain an open ended application if the extensions have to keep each others dependencies with their versions in mind.

 

Thank you,
Szili 

 

Jun 21, 2010 at 4:29 PM

@szili

It's possible to deal with this situation in the desktop CLR, but I dont think the same holds for Silverlight. That said, I believe as long as the assemblies have different identities you wont have any problem. Note that version is something that contributes to the version identity.

Did you try this scenario and got an exception/cast problem?