
Introduction
Silverlight applications are not run on the server, this allows developers to create really rich user interfaces with a ton of options. This great, but it also requires developers to write a lot of XAML, code and add a lot of images and other resources to the silverlight application. This causes the application to grow rapidly in size. It’s especially a problem because all that data needs to be downloaded from the server. Performance can become a real issue when the user has te download a total of 5MB or more just to run your application.
In this article I will talk about a few tricks to reduce the size of your silverlight application and thereby reduce the time it takes the application to start on the client.
Remove that assembly
By default Visual Studio will add quite a lot assemblies to your silverlight applications. Chances are you don’t need all of those assemblies.
The first step in optimizing your silverlight application for size is to remove excess assemblies from the application. A good way to achieve the desirect effect is to remove all assembly references, except for the System reference.
After that you will need to recompile and check for any compile errors that are caused by missing references. A lot of the errors will most likely be caused by unused using statements (or import statements in VB.NET). A quick way to get rid of these unused usings is to right click on them in Visual Studio 2008 and choose Organize usings / Remove unused usings.
Reducing size even more
The silverlight XAP package format is actually a ZIP container with a special manifest inside that is recognized by the silverlight runtime. The package that Visual Studio 2008 will create however is not compressed.
Another tip to get more bang for the megabyte is to unpack the XAP package and repack it using Winzip, Winrar or any other zip application. Because the XAML files inside are plain text it is possible to reduce size quite a bit this way, depending on the content of the application (The amount of XAML and the amount of code contained in the package).
Moving stuff around
The previous tips work great when building a single silverlight application, but when you work in an environment that hosts multiple silverlight applications or build a modular application using composite WPF it gets even better when you start moving stuff around.
Silverlight has the notion of application library caching. This allows developers to package external references as separate zip containers and place them either at the same location as the XAP package or when you’ve got the chance, place them at a central repository in a webfarm.
Each time a silverlight application that uses application library cache starts, it will check if all external deployment parts are available from cache. If a part is not in the cache the application will download it from the central location. Otherwise it will be loaded from the cache on the client requiring no download.
This doesn´t actually reduce the overall size of the deployment of your silverlight application, but it will however improve performance over the course of several runs or even several applications when you place the external references at a central location in the webfarm.
You can find information on how to setup application library caching here: http://msdn.microsoft.com/en-us/library/dd833069(VS.95).aspx
Conclusion
As with all new technology silverlight adds both new ways to build great applications and new challenges for developing building those applications.
The tips in this article should help developers meet the challenge of keeping startup time of their applications down by reducing size.