Take the 2-minute tour ×

It is necessary to move 'standard' assemblies out of the xap-file (Silverlight 4 application). I had a similar problem (http://stackoverflow.com/questions/3329731/silverlight-how-to-handle-standard-assemblies) and got a good link with deep explanations. But not all is clear there.

After I've switched on the 'Reduce XAP size by using application library caching" the size of my xap-file was decreased in twice, the following assemblies were moved out into separate zip-files:

  • System.ComponentModel.DataAnnotations;
  • System.Windows.Controls,
  • System.Windows.Controls.Data,
  • System.Windows.Controls.Data.Input,
  • System.Windows.Controls.Input,
  • System.Windows.Controls.Navigation,
  • System.Windows.Controls.Toolkit;
  • System.Windows.Data.

But still there are few others that seems like good candidates to be moved out into separate files:

  • GalaSoft.MvvmLight.SL4,
  • Microsoft.Practices.ServiceLocation,
  • Microsoft.Practices.Unity.Silverlight,
  • System.Windows.Controls.Toolkit.Internals.

All these assemblies are referenced from the Silverlight application (and also from Silverlight Projects that use these assemblies).

Could you please explain:

  • Q1. What is a difference between these mentioned assemblies?
  • Q2. How to move these 4 assemblies into a separate zip files too?

Thank you very much!

P.S. Probably, the answer on my question is in the text:

Add a reference to a library assembly in the Silverlight SDK, or to any assembly accompanied by a valid assemblyShortName.extmap.xml mapping file.

But I don't understand what does that mean. If I correctly understand, I need to add a reference on those assemblies (that I want to move out) into a Silverlight SDK. But how to do that? Thanks.

share|improve this question
add comment

1 Answer

up vote 8 down vote accepted

A1) The difference between the two lists is that the first set of assemblies has already defined the necessary *.extmap.xml files, which are used by Visual Studio to automatically package each assembly in a zip file, which is then cached independently on the client (via the web browser).

If you look in this folder (adjust the installation drive location as needed):

C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client

You'll see that there are *.extmap.dll files for nearly every common Silverlight assembly (if not all). For example, here's the content of System.Windows.Data.extmap.dll:

<?xml version="1.0"?>
<manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    <extension downloadUri="System.Windows.Data.zip" />


If you follow the documentation located here, you'll see how this is built. Most parts should be obvious, with the only unusual aspect being the extension element potentially. By putting a file name in the downloadUri attribute, the assembly is automatically packed into that file (it's a zip file, but the extension can be anything you'd like).

When you reference the assembly such as System.Windows.Data, it discovers this file and uses it during the build to create the zip file, System.Windows.Data.zip. If two or more referenced assemblies both share the same downloadUri destination file name, they will be automatically combined into a single file at build time.

A2) You can follow that pattern and create *.extmap.dll files for each of the assemblies you have in the second list.

The xml file should be located in the same folder as the assembly that you'd create.

For the GalaSoft.MvvmLight.SL4, (as an example, I don't have this component installed, and don't know if it's signed). The file would be named:


It's contents would look something like this:

<?xml version="1.0"?>
    <version>#.#.#.#</version> <!-- needs the version number -->
    <!-- if there's a public key token, put it in this element, and
        uncomment it -->
    <!-- <publickeytoken></publickeytoken> -->
    <extension downloadUri="GalaSoft.MvvmLight.SL4.zip" />

Once that file exists, Visual Studio will use it to build a zip file named GalaSoft.MvvmLight.SL4.zip. This all happens automatically once you reference the dll (as long as the extmap.xll file is side-by-side with the original assembly).

share|improve this answer
Excelent! Thank you very much! –  Budda Jul 31 '10 at 2:30
add comment

Your Answer


