Sergey Barskiy's Blog

I am continuing discussing new features on Silverlight 3.0.  Current topic is assembly caching. 

In Silverlight 2.0 all assemblies that your application needed would have to be included in your XAP file(s).  In Silverlight 3 you can force browser to cache one or more assemblies that your application needs.  In case of caching your can tell Silverlight runtime to pull these cached assemblies from a predefined location.  This location can be the same folder as your Silverlight XAP file or anywhere else on the internet.  To cache assemblies, you can turn on caching option in project properties:

What you will notice if you do that, that Microsoft assemblies such as System.Windows.Controls.Data (contains DataGrid) will not be included in your XAP file.  Instead if you look at the manifest file inside your XAP file, you will notice that this DLL is pulled at runtime from the same folder as your application.  The information about this is incluided in assembly manafiest in your main XAP file.  Here what it would look like:

<Deployment
xmlns=http://schemas.microsoft.com/client/2007/deployment
xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
EntryPointAssembly="CompanySLApp"
EntryPointType="CompanySLApp.App"
RuntimeVersion="3.0.40624.0">
  <Deployment.Parts>
    <AssemblyPart x:Name="CompanySLApp" Source="CompanySLApp.dll" />
  </Deployment.Parts>
  <Deployment.ExternalParts>
    <ExtensionPart Source="System.Windows.Controls.Data.zip" />
    <ExtensionPart Source="UtilityFunctions.zip" />
    <ExtensionPart Source="System.Windows.Controls.Data.Input.zip" />
    <ExtensionPart Source="System.Windows.Data.zip" />
    <ExtensionPart Source="System.ComponentModel.DataAnnotations.zip" />
  </Deployment.ExternalParts>
</Deployment>

If you try to do the same with your assembly (for example you have a common assembly shared between two Silverlight applications), your will notice that it is still included.  The reason for that is that compiler is looking for XXX..extmap.xml where XXX is your assembly names without DLL extension.  So, all your need to do is create one.  You can look for an example in C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Libraries\Client folder for any extmap files for Microsoft assemblies.  You can use a utility to generate your own too.  (http://www.devcorner.info/Sources/Emm.zip).  Once you generate extmap file for your assembly, make sure it is located in the same folder as the assembly dll.  Once you rebuild your solution, you will find XXX.zip file in ClientBin folder that contains your XXX.dll assembly file.  Now, at runtime browser will cache that assembly for you, saving download time during application start up time.  Of course, this depends on how caching is setup for virtual directory that contains your Silverlight application.  You can also pass addition parameters to emm.exe utility and force it to setup download URL for your included assembly that point to an absolute URL somewhere else.  Using this feature for example, you can host assemblies that you can include in many applications on a separate server with a predefined URL.

Please feel free to ask questions about this feature.  You can upload sample application that uses assembly caching here.

As I mentioned before, I will be working on a series of posts on new features in Silverlight 30.  This post is all about ElementName binding.

Probably my favorite feature in Silverlight 3 that affects developers writing business applications is addition of ElementName property to Binding object.  This features existed in WPF since version 1, but was missing from Silverlight 2.0.  The basic strategy behind the feature is the ability to bind a property on one UI element to a property on another UI element.  Here is a very common scenario in a business application that this features makes much simpler to implement.  Say, you have two co-dependent combo boxes.  For example, you have a combo box  with a listing of states, and once a state is selected, second combo box is populated with a list of cities for that state.

The basic syntax for ElementName binding is as follows:

In my case, I am going to illustrate the feature by having a list of dozens, each with a list of numbers that belong to that dozen.  Here are my classes:

Now, I am going to add my Dozens class as a resource to a xaml page:

The last step is to tie two combo boxes together:

Here is the summary of what we did.  We used Dozens class (the list of Dozen objects) that was populated when its constructor was invoked as part of resources collection initialization.  Then we used this object to populate ParentCombo with data.  We set DisplayMemberPath to show a desired property in combo box.  Then we used SelectedItem property from ParentCombo to be the source of items in ChildCombo.  As the user selects an item in ParentCombo, we can see that list of items inside ChildCombo is changing without any code-behind.  We also use dotted syntax (Path=SelectedItem.Items), so we can tie the eaches collection in dozens object to be the item source for another UI element.  In our case SelectedItem of ParentCombo is actually an instance of a Dozen object.  Items property of it gives us eaches collection.  Simple, yet very powerful feature.

You can download this sample project here.