Application Library Caching support for the Silverlight Toolkit

Posted 20 October 2009  

We previously received user feedback that we should ship the Application Library Caching manifest files along with the Silverlight Toolkit, to help reduce the size of .Xap files and cache the important libraries for future use in applications.

This advanced feature in Silverlight 3 allows libraries that your app depends on to be delivered outside the primary .Xap for your app, allowing the browser to cache the extensions for future use. This will speed up the startup experience for your frequent users if you update the app but don’t have changes to those libraries – it can save you bandwidth costs when hosting on a CDN, too!

We haven’t able to get the files included in the setup experience yet, so I wanted to share with the community the .extmap.xml files to use the feature before we release it in a future Silverlight Toolkit release.

Yes, the next release will have this feature built-in, so this is a stop-gap. Great details on how the feature works here.

What a library cache file looks like

The XML file is quite basic: it lists the assembly name, assembly version, public key token, and then the path information. Here’s the System.Windows.Controls.Toolkit.extmap.xml file:

<?xml version="1.0"?>

<manifest xmlns:xsi="" 







    <extension downloadUri="" />



Downloading and install the files

Download a ZIP (4 KB) of the extmaps for the toolkit here. These files work with both the July 2009 and October 2009 releases of the toolkit, though I’d recommend using the latest available official release!

After downloading, extract the files. For the best experience, copy the files side-by-side with the Silverlight Toolkit binaries. We added a link to the Binaries folder in the October release of the toolkit to make it quick to get there, too:


On my 64-bit machine, the folder is ‘C:\Program Files (x86)\Microsoft SDKs\Silverlight\v3.0\Toolkit\Oct09\Bin’

You’ll be asked to elevate when you copy in the extracted .extmap.xml files, as the program location is system-wide. Allow the operation by clicking ‘Continue’:


Now you’re ready to go – the Silverlight build tasks will detect the presence of these small XML files and use that information to zip up the dependent libraries for your app.

How this can help

Now, I have this amazing Silverlight 3 app that uses the charting components from the Silverlight Toolkit:


When I build the app, I see that the original .Xap file is 345 KB. This is a debug build of the app, btw.

It includes the toolkit’s charting components, the primary toolkit assembly, plus the control library from the Silverlight SDK.

It is all of great value, but does add up in bytes – and the bytes for those libraries don’t change very often, making them a great target for this caching.


Turning on the feature for your Silverlight Application project

You need to opt-in to the application library caching feature.

Right-click on your Silverlight application project in Visual Studio (applies the same in Visual Studio 2008 and Visual Studio 2010 Beta 2) and select ‘Properties’

Navigate to the Silverlight tab and check the ‘Reduce XAP size by using application library caching’ box:


Save the changes and then build your project. Now, we see that there are 3 new .Zip files, and the original .Xap. The .Xap is only 41 KB, plus the first time someone uses your application from the server, their browser will also go ahead and download the 3 .Zip files equaling the rest of the original app’s size.


NOTE: The reason this is opt-in is that it’s more involved for publishing, since you need to remember that not only do you need the .Xap file for your app, you also need to store the .Zip file(s) of the libraries alongside as well.

This will be a feature in a future release of the Silverlight Toolkit

We shipped the October 2009 release of the Silverlight Toolkit on Monday, focusing primarily on delivering the necessary design features for enabling a great Visual Studio 2010 Beta 2 story.

We’ve also been working diligently on longer-lead items for the next release of the Silverlight Toolkit, such as integrating the generation of these .extmap.xml files into our build process. Next, we’ll add them to the setup and with the next release, you won’t need this blog post to take advantage of the feature.

If you’d like to learn more about the feature, Tim Heuer really covered this well earlier this year in this post.

Hope this helps. Special thanks to user ‘TimmyG’ on CodePlex who initially reminded us of this!

Jeff Wilcox is a Principal Software Engineer at Microsoft in the Open Source Programs Office, helping Microsoft scale to 10,000+ engineers using, contributing to and releasing open source.

comments powered by Disqus