Assembly Caching in Silverlight 4 for Performance Gains

The smaller the XAP file, the quicker your application loads. Assembly caching in Silverlight 3 and 4 does exactly that. Let us understand what assembly caching is.

By default, when you deploy a Silverlight application, all the dependant assemblies get deployed in a single .xap file. So let us say if you have an application that uses System.XML.Serialization, System.ServiceModel.Syndication etc, then all these assemblies get deployed in a single .xap file. Shown below is a screenshot of the build process with all the assemblies added to a single .xap file.

single xap file

This bulky .xap file when called by the Silverlight Plug-in from your browser, increases the application load time and if there are multiple application using the same assemblies, they cannot share the dll’s, that were already loaded earlier. What a waste!

However if you are using Silverlight 3 or above, you can make use of Assembly Caching which is a deployment mechanism to share common dll’s between applications as well as package dependant assembly outside the xap, there by keeping each .xap file small. It makes a lot of sense to cache these library assembles as they do not change so frequently. When the Silverlight app is first accessed by your browser, the plug-in downloads the .xap and all these external assemblies, and caches it. For each subsequent request, once the browser downloads the xap file, there’s no need to download the dependant assemblies, since they are already cached and can be reused instead. This also leads to sharing common dll’s between applications and reducing the app load time.

Enable Assembly Caching

To enable assembly caching in your Silverlight project, go to the Solution Explorer, select the Silverlight application project > Right Click > Properties > In the Silverlight tab, select Reduce XAP size by using application library caching. Save the settings.

enable app caching

Now when you deploy this application with the Assembly Caching setting enabled, the result is as shown below:

Before Assembly Caching - After Assembly Caching

after app caching

As you can see, all dependant assemblies are compressed and zipped individually, which makes them easier to load, cache and reuse.

Assembly Caching: Important Points to Consider

Let us wrap this discussion by going through some important points:

  • Application caching does not work for out-of-browser applications.
  • If the user clears the browser cache, all the cached assemblies also get removed.
  • To test assembly caching, use a tool like Fiddler or Firebug and monitor the files that get downloaded for the first request and subsequent requests.
  • The files to be downloaded are determined by using the ExtensionPart entry in the Deployment.ExternalParts section in the assembly manifest.
  • If you happen to deploy a new assembly, then the application detects this and replaces the old version with the new one and caches it.
  • Upgrading the application is easier as the upgrades are quickly downloaded.

In a subsequent post, we will see how to configure your own assemblies to use Application caching.

About The Author

Suprotim Agarwal
Suprotim Agarwal, Developer Technologies MVP (Microsoft Most Valuable Professional) is the founder and contributor for DevCurry, DotNetCurry and SQLServerCurry. He is the Chief Editor of a Developer Magazine called DNC Magazine. He has also authored two Books - 51 Recipes using jQuery with ASP.NET Controls. and The Absolutely Awesome jQuery CookBook.

Follow him on twitter @suprotimagarwal.

No comments: