In Silverlight 2, if I make use of an additional assembly such as System.Xml.Linq.dll then I need to reference it from Visual Studio and then when I build I’ll end up with a XAP file that contains;

• My assembly for my application
• My manifest for my application ( which will list at least my assembly and System.Xml.Linq.dll )
• A copy of the System.Xml.Linq.dll

So, every time a user downloads my application they are also paying for the download of System.Xml.Linq.dll and if they have other Silverlight applications that they are using which also make use of System.Xml.Linq.dll then those applications cannot benefit from the fact that my application has already caused that assembly to be downloaded to the client.

Note – System.Xml.Linq.dll is just an example here, there are plenty of other assemblies that would be common across lots of Silverlight applications.

In Silverlight 3, it’s possible to have some of these assemblies downloaded from Microsoft as a way of;

1. Reducing the size of your own XAP
2. Allowing for the fact that other XAPs may well have already downloaded the assembly and therefore remove the need for it to be downloaded again for your application

If you take a look at your equivalent of;

c:\program files\microsoft sdks\silverlight\v3.0\libraries\client

and do a search for *.xml you’ll find various files named .extmap.xml and if you take a look at an example like System.Xml.Linq.extmap.xml you’ll find a file like;

<?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.Xml.Linq</name>
    <version>2.0.5.0</version>
    <publickeytoken>31bf3856ad364e35</publickeytoken>
    <relpath>System.Xml.Linq.dll</relpath>
    <extension downloadUri="http://go.microsoft.com/fwlink/?LinkId=142576" />
  </assembly>

</manifest>

what this file is doing is providing a Microsoft link whereby System.Xml.Linq.dll can be downloaded by a Silverlight 3 application rather than you having to provide that assembly inside your own XAP.

If you go to the property pages of a project in Visual Studio with the Silverlight 3 Beta tools installed then you’ll find a new option that looks something like this;

and if you select that option then you’d notice that your generated application manifest changes. For instance, mine ( which is only referencing System.Xml.Linq.dll ) goes from this;

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

to this;

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" EntryPointAssembly="SilverlightApplication18" EntryPointType="SilverlightApplication18.App" RuntimeVersion="3.0.40307.0">
  <Deployment.Parts>
    <AssemblyPart x:Name="SilverlightApplication18" Source="SilverlightApplication18.dll" />
  </Deployment.Parts>
  <Deployment.ExternalParts>
    <ExtensionPart Source="http://go.microsoft.com/fwlink/?LinkId=142576" />
  </Deployment.ExternalParts>
</Deployment>

and when I come to run this application in the browser, I can see (with Fiddler) the following traffic being sent to Microsoft.com from my Silverlight application;

in order to get hold of the zipped version of System.Xml.Linq.dll.

Note – as far as I’m aware, this is only available for Microsoft assemblies today.

This is one of a series of posts taking a quick look at Silverlight 3 – expect them to be a little “rough and ready” and that they’ll get expanded on as I’ve had more time to work with Silverlight 3.