If you’ve been programming in Silverlight for long, you may have noticed the project setting “Reduce XAP size by using application library caching” in you Silverlight project’s settings. You may have even checked it on to see what happens.
If you did try it, most likely nothing happened. This is because there are a few simple prerequisite steps you have to take in order to take advantage of application library caching.
In this blog post, I’ll step you through those set up steps. But first, why would you want to use application library caching?
Why Use Application Library Caching?
In short, there are two different reasons:
1) Caching shared references on the client for sharing between different Silverlight applications, or
2) Smaller application update downloads when some referenced libraries change, but not others.
As you probably already know, Silverlight applications are distributed in a XAP file , which is just a ZIP archive that also includes a manifest file in XML format. In fact, if you rename any .XAP file to end in .ZIP, you can open it and see its contents.
The contents of a XAP file include your application DLL plus a DLL for each of the referenced libraries in your application (that aren’t already part of the .NET Framework). Enabling application library caching splits each individual referenced library out into its own ZIP archive. These are then downloaded separately (but automatically) by the Silverlight applications that references them.
Practically speaking, enabling application library caching on a Silverlight application with two referenced libraries will change the contents of the ClientBin directory—the one that hosts the XAP file—from something like this:
Figure 1: Without application library caching
to something more like this:
Figure 2: With application library caching
Notice how much smaller the XAP file is in Figure 2. This is because the referenced libraries, each about 3.7 MB in size, have been removed and placed in their own separate ZIPs
Now for a little more detail on the different scenarios for using application library caching…
Scenario 1: Sharing References
Consider a scenario where you have multiple Silverlight applications hosted on the same domain which share some of the same referenced libraries. Every time a user accesses one of these applications for the first time, they have to download the entire XAP file, including all the referenced assemblies they may have already downloaded with another one of your applications.
Application library caching splits these references out so your user only has to download the ones they haven’t already downloaded.
Scenario 2: Smaller Application Updates
When you update your application, sometimes you make a small change to just one of the referenced libraries and now changes to anything else. In cases like this, it’s kind of ridiculous that all of your users have to re-download your entire application, including ALL of the unchanged referenced libraries, just to get the one changed file.
Application library caching avoids this problem by splitting all the references out into their own ZIP file downloads so that only the changed one needs to be downloaded again. Because the individual files are still zipped, the user still gets the download speed advantages of the file compression.
Setting Up Application Library Caching
Follow these steps to enable application library caching for you own Silverlight library assemblies:
1) Strong name your assembly
Each assembly must have a strong name key to be eligible for application library caching. Open the Visual Studio command project to your assembly’s root directory and type:
sn –k [YourAssemblyName].snk
Add the file to your class library project and open your library project’s settings to the Signing tab. Check “Sign the assembly” and select your SNK file from the drop down. Rebuild your project and leave the Visual Studio command prompt open for later use.
2) Create a [YourAssemblyName].extmap.xml file for your assembly
Add a new text file to the root of your class library project and rename it to [YourAssemblyName].extmap.xml. This file and its content are the key to making application library caching work. Open the file and paste in the following XML:
<?xml version="1.0"?>
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<assembly>
<name>[YourAssemblyName]</name>
<version>[YourAssemblyVersion, probably 1.0.0.0]</version>
<publickeytoken>[YourAssemblyPublicKeyToken]</publickeytoken>
<relpath>[YourAssemblyName].dll</relpath>
<extension downloadUri="[YourAssemblyName].zip" />
</assembly>
</manifest>
Change [YourAssemblyName] to your assembly’s actual name and [YourAssemblyVersion] to the version set in you project’s AssemblyInfo.cs file—most likely 1.0.0.0 if you haven’t changed it already.
To retrieve your assembly’s public key token, return to the Visual Studio commend prompt, change to /Bin/Debug/ (or wherever you built the assembly to). Type the following:
sn –Tp [YourAssemblyName].dll
Copy the token that appears in the output after “Public key token is” and replace [YourAssemblyPublicKeyToken] in your .extmap.xml file with it.
Change the “Build Action” property of the .extmap.xml file to “Content” and the “Copy to output directory” setting to “Copy if newer”
3) Enable application library caching for your Silverlight application
Now you return to where we started by checking the “Reduce XAP size by using application library caching” check box in your Silverlight application project’s settings.
Rebuild your solution and look at the output directory (ClientBin) to see if it worked!
For reference, I created this sample project that is set up correctly to use application library caching.