Friday, March 18, 2011

Silverlight: MEF and other approaches

Hi all.

Today I'd like to concentrate to the discussion about the MEF: a relatively new framework for dynamically loading Silverlight content.
It was amazing from the first point of view, and we have decided to use it. The process started.
Of course it's easy: use some simple attributes, mark the exportable types you want in your .xap packages with those attributes and that's it - you'll have them whenever you'll need them, and everything will be ok.
Yes, all this is right, BUT ...
There is a big BUT about this MEF: when you application will come a bit bigger - and it will come to this stage, because you are already using MEF, so that was your intention to avoid loading such a big application, you'll find out that instead of downloading each library/assembly only once from the server, you'll download it as many times, as you have it in each downloadable .XAP.
This became a big problem, when my app with all those xaps grown to ~14Mb. What to do?
Of course there is always a better way to go. And here one, which I have implemented and is satisfied with:
The .Net Framework is such a good thing :) I have created a simple attribute, which was aimed to mark the assembly references for the assembly it's applied to. And the second part, is that I've created a small asynchronous Assembly Loader, which is using this information from the described attribute, and downloads all those dependencies, when you ask it to download an assembly. If this assembly is already downloaded, you'll just get that instance, otherwise it will download it, it's references, and when everything is ready to be used, it fires this amzaing "AssemblyLoaded" event, which to I was able to react. So finally, avoiding this dll duplication (another .dll hell) I've reduced the size of the app from 13.6Mb to 3.8Mb. And one more thing - it works excellent and much faster.


Unknown said...

You say that you are no longer using MEF, what caused this decision? MEF does not need to download your assemblies for you, the catalog does this.

Did you write your own catalog? Or have you replaced the use of MEF entirely? If so, why?

Unknown said...

I think the answer for question "why" is in the post. Related to what I've replaced it with - I'm downloading the assemblyes solely and load those with appropriate references.

Jone said...

did you notice about Deployment Catalog and recomposition using MEF?

Unknown said...

Hi Jone.

In fact, Yes. I've replaced that mechanism with the one described.

Bogdan Zamfir said...

Please, can you provide some sample code on your implementation? It is very interesting, but I'm new to MEF / SL4 and not sure how to approach it.
Thanks a lot

Bogdan Zamfir said...
This comment has been removed by the author.
Unknown said...

Will make the soureces public soon.

Unknown said...

Hi all.

As promised, here is the solution which was described in the post:

HealthFitnessPassion said...

where is your solution

As promised, here is the solution which was described in the post link is not working plz coreect it

Unknown said...

Sorry for mistaken address. Here is the correct one:

Anonymous said...

I'm working on a complex Silverlight application with multiple sub-applications. We keep the child .xaps small by referencing all the common assemblies in the parent .xap and setting the reference's Copy Local to false in the child xaps. Each sub-app comes out to 1 MB.

Georges said...

Well, not sure about the version of MEF you were using and whether this was available or not by that time but in all references properties you have a "CopyLocal" that you should set to false if you're sure that that DLL has already been downloaded... which should be the case for all DLL that are MEF related. CopyLocal is telling VisualStudio to add the DLL in the XAP file or not.
Then, using that feature, I also created a XAP file to "preload" DLLs that I could need later on on multiple XAPs.
This way you might not be able to solve all your issues but this might be a huge optimisation.


Unknown said...

Hi Georges, Foson.

Thanks for your comments, now I do agree with you, because has deep understanding on how MEF works. Actually the usage was improper. And now I understand that I've reinvented the wheel, instead of leaving that to MEF.