Webucator Blog

What’s In A Silverlight 4 XAP File?

The purpose of this post is to examine the output file of a Silverlight 4 application.  In addition to the default output I will cover a couple of options that affect how the XAP file is packaged.

When a Silverlight project is built in Visual Studio all of the files, XAML and .NET code, are compiled into a single DLL.  This DLL file is then compressed into a zip file that gets named with a .xap extension rather than the traditional .zip.  In addition to XAML and code files, graphics and media files are compiled by default into the DLL assembly as well.

One way to verify the contents of a XAP file is to rename it with a .zip and open with windows explorer and you should see at a minimum the .dll assembly file along with a .xaml manifest file.  The following image is an example.

The ExploringXapFile.dll is the main output assembly file from the following XAML and code-behind built in Visual Studio 2010.


This basic Silverlight page has just a single line of code in the code-behind file that updates the TextBlock with the contents of the TextBox.


The controls used in this XAML page are all instances of classes defined within the core assemblies that are part of the Silverlight plug-in.  For this reason there is no extra assembly files packaged inside the XAP file.

However if I add the following XAML to the page:


Dropping these tree controls onto the page in Visual Studio 2010 will also add a new namespace declaration and assembly reference:


The assembly System.Windows.Controls is not part of the base assemblies included with the Silverlight 4 plug-in.  This means that the assembly will need to be included in the XAP file as the following image illustrates:


Most of the time including this extra assembly in your XAP file would be fine.  There is an alternative though.  You can separated the System.Windows.Controls assembly out and have the client’s browser cache it locally.  This is called “application library caching”.  If the client already has a cached copy of the assembly it does not need to be downloaded again.  This would obviously decrease the amount of content that needs to be downloaded for the application to run.

To configure the Silverlight project to use library caching you right-click on the project in Solution Explorer and choose the “Properties” option.  This will open the properties tab for the project and then you check the box labeled “Reduce XAP size by using application library caching”, as shown in the following screen capture:


The result of this setting is that the System.Windows.Controls.dll file will be packaged separately in its own ZIP file.  The following screen capture is of the hosting web site’s ClientBin folder.  It’s from this folder that the client downloads the files for the Silverlight application.  The client will only download the ZIP file if it does not already have a current copy in its cache.


It is also possible to control how resources like graphics files are stored in the Silverlight applications output.  In the current example I have a logo.jpg file of the Webucator logo displayed at the top of the page using the following XAML:


The default properties of the logo.jpg file in the Silverlight application is to include it as a “Resource” which causes the folder and image to be embedded in the DLL file along with the XAML and code.  If I select the properties menu of the logo.jpg by right clicking it in Solution Explorer I get the following:


Here I have changed the default of the “Build Action” from “Resource” to “Content”.  This tells Visual Studio to compile Image folder and files within it separately from the DLL file but still within the compressed XAP file.  The following is a screen capture showing the XAP file contents with this setting:


path to the image file must also be modified in the XAML source code to the following:


Even though Visual Studio 2010 beta 2 build is complaining about the path it works fine.  What can I say, it’s beta…

The XAP file is Silverlight’s delivery mechanism for getting rich content down to the plug-in.  As I have demonstrated, you have some control over how that XAP file is packaged.  The default settings are probably sufficient in most scenarios but it’s nice to know that there is alternatives that might be more beneficial in certain situations.