A Silverlight application, once compiled, will end up as a XAP (pronounced as zap) file. That XAP file, which is actually a ZIP file renamed, will contain your compiled code in the form of a DLL file, which is a manifest file named AppManifest.xaml that describes your application to the Silverlight runtime engine and possibly some resources such as images, web service connection information, or any other type of content your application might need.

Due to the fact that a XAP file contains more than just compiled code, there may be times when we need to edit its content, which is where knowing the fact that "the XAP files are basically the ZIP files" comes in handy.

Consider the following scenario:

You are developing a Silverlight application that needs to access a database in order to display data from it. To access the database, you will connect to a WCF web service that grabs the data and sends it back to your application in the XML format. In most cases, the WCF web service won't be hosted on the same machine in both development and production environments and, thus, will have a different IP address on each. As we have mentioned earlier, the XAP file contains, among other things, the web service connection information for our application inside a file called ServiceReferences.ClientConfig. So, before we move our application from a development to a production environment we need to edit this file and change the address of the WCF web service from a testing environment address to the production address.

In order to run our Silverlight application, the browser will download our XAP file to the client computer, which means file size may be an issue for users with limited bandwidth or a slower connection. We may try to reduce the size of our XAP file by re-zipping it using a stronger compression rate. But, this will come at the expense of slower decompression of the XAP file on older machines, and the slower the decompression rate is, the longer it will take for your application to start running.

A better method to decrease the size of your XAP file would be using the "application library caching" option. The application library caching, also known as assembly caching, is a packing method, which avoids packing the DLL files into your XAP file, and instead zips them into individual files alongside it. Using assembly caching may greatly reduce the size of your XAP file, providing faster initial loading time for your application.

To use assembly caching, right-click on the project name in Visual Studio 2010 and select Properties. In the new dialog box, select the Reduce XAP size by using application library caching option, as shown in the following screenshot:

You may be wondering at this point how the Silverlight runtime engine knows that we used the assembly caching option, and that it needs to download a list of external DLL files. The answer to this question is simpler than you might imagine—the AppManifest.xaml file.

We have mentioned the AppManifest.xaml file earlier when we discussed the content of a XAP file and now we can elaborate more about it. The AppManifest.xaml file has one important role—it is responsible for describing our application to the Silverlight runtime engine. Whenever you create a new Silverlight project, Visual Studio 2010 creates this file as part of the project and updates it throughout the project lifetime if necessary. As Visual Studio is responsible for updating this file, it would be rare that we need to update this file by hand ourselves.

Visual Studio 2010 will generate the content of the file, once you compile your Silverlight project. Let's take a look at a basic example of an AppManifest.xaml file:

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="SilverlightApplication2" EntryPointType="SilverlightApplication2.App" RuntimeVersion="4.0.60310.0">
<Deployment.Parts>
<AssemblyPart x:Name="SilverlightApplication2" Source="SilverlightApplication2.dll" />
<AssemblyPart x:Name="System.Windows.Controls.Navigation" Source="System.Windows.Controls.Navigation.dll" />
<AssemblyPart x:Name="System.Xml.Linq" Source="System.Xml.Linq.dll" />
</Deployment.Parts>
</Deployment>

As can be seen from the preceding code snippet, the Deployment element has three attributes as follows:

Under Deployment lies the Parts section. This section houses one or more AssemblyPart entries, each of which point to a DLL file that our application is using. The first entry is usually our compiled Silverlight application, which also contains the entry point class that was specified under the EntryPointType attribute of the parent Deployment tag.

Other than Parts, the Deployment element may also contain an ExternalParts section. This section will be visible only if we have used the application caching option. This section tells the Silverlight runtime engine which files it needs to download, other than the XAP file, in order to run the application. The ExternalParts section will contain one or more ExtentionPart entries, each of which point to an external ZIP file.

An example of the ExternalParts section may look like the following code snippet:

<Deployment.ExternalParts>
<ExtensionPart Source="System.Windows.Controls.Navigation.zip" />
<ExtensionPart Source="System.Xml.Linq.zip" />
</Deployment.ExternalParts>

In our sample, the Silverlight runtime engine will have to download two external files to get the application running.