Configure an assembly for use with application library caching

1. Create a mapping file in the same location as your assembly. This file must have the same name as your assembly, replacing the .dll file name extension with ".extmap.xml". For example, the Silverlight SDK assembly System.Windows.Controls.Data.dll has a mapping file that is named System.Windows.Controls.Data.extmap.xml.
2. Add configuration data to the mapping file as shown in the following example, replacing the values in the assembly element to match your assembly.

<?xml version="1.0"?>

<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

          xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <assembly>

    <name>System.Windows.Controls.Data</name>

    <version>2.0.5.0</version>

    <publickeytoken>81bs3816af364e35</publickeytoken>

    <relpath>System.Windows.Controls.Data.dll</relpath>

    <extension downloadUri="System.Windows.Controls.Data.zip" />

  </assembly>

</manifest>

The name, version, and publickeytoken elements must match the corresponding assembly metadata. The relpath element indicates the assembly file name. Finally, the extension element indicates the name of the packaged external part through the downloadUri attribute. The downloadUri attribute value is used to populate the ExtensionPart.Source property in the application manifest, as shown in the following manifest excerpt.

<Deployment.ExternalParts>

  <ExtensionPart Source="System.Windows.Controls.Data.zip" />

</Deployment.ExternalParts>

The Source property indicates the name of an application library package or an absolute URI that identifies an application library package. Files identified by name only are retrieved from the same server location as the .xap file.

If the downloadUri value is a file name, Visual Studio provides the following support when you add a reference to the assembly:

•          The build system packages the assembly into a zip file that has the specified file name. This file is copied to the output directory alongside the .xap file.

•          If you add references to more than one assembly with the same downloadUri file name, the build system compresses them all into a single zip file.

•         The .zip extension is not added automatically. Although the packaged file is a ZIP file, you can use whichever file name extensions that your server requires.

If downloadUri is an absolute URI, the build system will not package the assembly. Instead, you are responsible for zipping the assembly and deploying it to the specified URI. This is useful for creating a single repository of libraries used by multiple applications. However, you should consider the following issues when you use an absolutedownloadUri value.

• If the URI is on a different domain than the .xap file, the domain must have a cross-domain policy file in its root folder.

• A URI is a globally unique identifier and can reference a very specific assembly file. This means that you can and should use a different URI for different versions of your assemblies. Additionally, you should continue to maintain each version-specific URI and assembly that you create when you deploy new assembly versions at updated URIs. This helps avoid potential issues when a .xap file built with one version of Silverlight attempts to load a library built with another version.

Reducing the XAP size

The whole reason for keeping XAP size small is so that your application loads as quickly as possible. This is important as a larger XAP can take extra seconds to load, which can be long enough for your users to leave your site and not come back.

Make sure that you worry about the XAP size from Day one of the project and make sure that its not too late to think about this.

There are many ways to reduce the XAP size. I have pointed out few of the points below:

Ø  Remove all the Images from the Silverlight application and place it on the WebApplication. This way you will be able to reduce the load on the XAP.

Ø  Use application library caching (it's just a project setting), by doing this all signed assemblies will be stored in separate ZIP files, this means: first time the user starts the application he will have to download all the content anyway, next time he will have to download only the main XAP file and the rest of ZIP elements will be retrieved from the browser cache, this solution is interesting if you share that signed assemblies between different Silverlight Applications.

Ø  Configure your assembly file to be included in the application library caching.

Ø  If you are using any resource files like static XML, etc. Make use of the Isolated Storage. This won't enhance the first load of the application, but in subsequent downloads you can check whether the resource is already available on the client local storage and avoid downloading it from the server. Make sure that you have a version number with the file name so that you download the latest file and delete the older ones. Also make sure that you have enough storage size as Silverlight allows only 1 MB initial size. If you need more space extend the storage size.

Ø  Reduce the code size by using the patterns and practices like MVVM, Light MVVM, Prism, MEF, etc.

Ø  Obfuscate your code.

Ø  Load assemblies on Demand, this trick are possible due to the Silverlight API, that allows us to load assemblies into the AppDomain. We need to download one using simple WebClient, load it and use Reflection to use its types and resources. Although this is tricky and kind of obsolete, one can find it interesting and implement it on his/her own.

Ø  Create nice looking and professional SplashScreen that will reduce the bad experience from downloading big xap package.

Introduction

This blog is mainly to share the knowledge that I get during the development using Silverlight. There will be a post made every week on any of the interesting topics. If there is any topic that you want me to specify, please post your comments so that I can have a post on that topic in later weeks.



Hoping to get all your support!.