As people become more aware of the fantastic things you can do with Silverlight, they’ve also realized one of the downsides of this can be increased XAP size.  The default way that Silverlight handles a XAP is to include all the required assemblies into that single compressed file.  This isn’t that bad when you’re working with a barebones Silverlight project, but once you start adding in different controls or 3rd party assemblies you are increasing your XAP size quite a bit in some cases.  And as we all know, a larger XAP leads to longer load times, and although people have been dealing with long load times on desktop programs for a while now (Hello, Visual Studio!), the average end user does not want to see this in Rich Internet Applications (RIAs).

The answer to this came in Silverlight 3 in the form of Application Library Caching (or as I’ll refer to it, assembly caching).  This is explained in pretty extensive detail by both the MSDN documentation as well as this post by Tim Heuer, but the gist of it is that you can move your assemblies outside of your XAP and just have them referenced by the application.  Once you’ve downloaded the assemblies once, they are present on your machine and you won’t have to re-download them in another XAP.

To make this a little more visible, let’s look at my super test application in all its glory:

Glorious application

In this, I’m making use of a handful of Telerik assemblies along with a few other more generic Silverlight ones.  I’ve also added another project to my solution, including the exact same assemblies, so here is a look at my solution explorer as well as ClientBin of the web application so you can see the size of the XAP files:

Non-cached view

If you can’t see that too well, the sizes for each SL app are 1989KB and 2252KB respectively- but wait, aren’t they sharing a lot of assemblies inside of those XAP files? 

Indeed they are- which is where assembly caching comes in.  For starters, we click the magic checkbox in Visual Studio:

Magic ALC checkbox

The “magic” here is that we’ve done the work for you and included the corresponding .extmap files for every Telerik Silverlight assembly, meaning that once you click that checkbox, you now have all the behind the scenes plumbing taken care of and you get an end result which looks something like this:

Cached Assembly view

I know what you might be thinking- my ClientBin folder exploded with all this extra stuff!  The extra stuff is actually all of the assemblies that were previously packed into the XAP files, leaving our actual XAP file sizes at 91KB and 92KB (for you math geeks, the XAPs are now around 4% of their previous size).  Everything else is outside of the XAP files now and downloaded apart from the XAP.

Now what are some advantages of this?  This solution shows one of the best examples I can think of… Say you are using Silverlight to create different islands of functionality in your app (like a stylin’ RadChart, for example), you don’t really want each XAP file to take a while to load up on the page.  With assembly caching, once you load the first XAP that includes those assemblies all of the compressed versions will be downloaded to the client machine.  Then when each additional XAP file will be able to load those cached assemblies instead of re-downloading them in each XAP file you have. 

To put the numbers together, say you go to the TelerikAssemblyCachingTestPage.aspx, you’ll be downloading 2257KB to get the first app running.  When you then navigate to ExtraSilverlightTestPage.aspx, you’re only downloading 91KB, everything else is already sitting on your machine from the first XAP you got.  Also, from a raw numbers perspective, without caching you’re downloading a total of 4241KB of data for two XAP files, whereas with caching you’re only downloading 2348KB.  Add another few XAPs uncached and you might be looking at a total of around 8mb of downloads, much of which is the same assemblies tucked away in the XAP files.  With caching, however, you are only adding the size of the XAPs, which in my small example are 91kb and 92kb respectively, but you get the idea.

So in summary, use caching when available, you’ll save yourself download time and your users will thank you.  And courtesy of the team here at Telerik, adding cached Telerik assemblies is as easy as clicking a checkbox in your project properties.

About the Author

Evan Hutnick

works as a Developer Evangelist for Telerik specializing in Silverlight and WPF in addition to being a Microsoft MVP for Silverlight. After years as a development enthusiast in .Net technologies, he has been able to excel in XAML development helping to provide samples and expertise in these cutting edge technologies. You can find him on Twitter @EvanHutnick.

Related Posts


Comments are disabled in preview mode.