Silverlight Out of Browser (OOB) applications are becoming more and more popular due to the convenience of being able to install and launch them locally. As Silverlight applications become larger and more composable, advanced techniques such as dynamically loading modules are also becoming more popular.
The "out of the box" Managed Extensibility Framework provision for dynamic modules is the DeploymentCatalog. This will download a XAP file based on a URI and integrate it with the current solution. It also works in OOB mode and will attempt to retrieve the URI from the same location as the in-browser version (the only caveat is that you must specify the absolute, rather than relative, URI).
What happens if the user is running on their desktop, and offline? This gets quite interesting. It turns out that most functions will simply use the browser cache, so if the items are cached then they will load with no problem. However, if the cache is cleared, you can run into problems.
To address this issue, I created the OfflineCatalog. This MEF catalog behaves like the DeploymentCatalog with a few exceptions. First, it will save any XAP file to isolated storage whenever it retrieves one, and second, if the application is OOB and offline, it will automatically load the XAPs from isolated storage instead of trying to fetch them from the web.
Instead of building my own catalog from scratch, I decided to cheat a little bit and use some of the existing catalogs "under the covers." To start with, we'll base the class on ComposablePartCatalog. I'm setting up some helpers — an aggregate catalog to aggregate the parts I discover, a list of assemblies to load from the XAP, and a static list of parts so that if I use multiple catalogs I won't ever try to load the same assembly more than once. It looks like this:
public class OfflineCatalog : ComposablePartCatalog
{
private readonly AggregateCatalog _typeCatalogs = new AggregateCatalog();
private readonly List<Assembly> _assemblies = new List<Assembly>();
private static readonly List<string> _parts = new List<string>();
public Uri Uri { get; private set; }
public OfflineCatalog(string uri)
{
Uri = new Uri(uri, UriKind.Relative);
}
public OfflineCatalog(Uri uri)
{
Uri = uri;
}
public override IQueryable<ComposablePartDefinition> Parts
{
get { return _typeCatalogs.Parts; }
}
}
This will asynchronously load, so I provide an event to "listen to" when the loading is complete:
... public event EventHandler<AsyncCompletedEventArgs> DownloadCompleted; ...
Now I can wire up the download - it will simply try to download the XAP using a web client if the application is online, and read it from isolated storage if the application is offline:
public void DownloadAsync()
{
if (NetworkInterface.GetIsNetworkAvailable())
{
Debug.WriteLine("Begin async download of XAP {0}", Uri);
var webClient = new WebClient();
webClient.OpenReadCompleted += WebClientOpenReadCompleted;
webClient.OpenReadAsync(Uri);
}
else
{
_ReadFromIso();
}
}
For this example, I just take the full URI and replace some of the non-friendly characters with dots to make a filename - that is how I'll store/retrieve the catalog from isolated storage:
private string _AsFileName()
{
return Uri.ToString().Replace(':', '.').Replace('/', '.');
}
Now I can easily read in the file and send the stream off for processing:
private void _ReadFromIso()
{
Debug.WriteLine("Attempting to retrieve XAP {0} from isolated storage.", Uri);
using (var iso = IsolatedStorageFile.GetUserStoreForApplication())
{
if (iso.FileExists(_AsFileName()))
{
_ProcessXap(iso.OpenFile(_AsFileName(), FileMode.Open, FileAccess.Read));
}
else
{
if (DownloadCompleted != null)
{
DownloadCompleted(this, new AsyncCompletedEventArgs(
new Exception(
string.Format(
"The requested XAP was not found in isolated storage: {0}",
Uri)), false, null));
}
}
}
}
Now it's simple to wire in the download event. Once downloaded, I simply write to isolated storage and then call the same method to parse it back out:
private void WebClientOpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
{
Debug.WriteLine("Download of xap {0} completed.", Uri);
if (e.Error != null)
{
// will try to read from ISO as a fallback
Debug.WriteLine("Catalog load failed: {0}", e.Error.Message);
}
else
{
var isoName = _AsFileName();
Debug.WriteLine("Attempting to store XAP {0} to local file {1}", Uri, isoName);
using (var iso = IsolatedStorageFile.GetUserStoreForApplication())
{
using (var br = new BinaryReader(e.Result))
{
using (var bw = new BinaryWriter(iso.OpenFile(isoName, FileMode.Create, FileAccess.Write)))
{
bw.Write(br.ReadBytes((int) e.Result.Length));
}
}
}
}
_ReadFromIso();
}
Notice if the load fails, I'll still try to read the isolated storage version as a fallback. Now we need to take a look at the "meat" of the method that reads from iso. The ProcessXap method does several things. The AppManifest.xaml provides us with a list of the parts (assemblies) contained. We parse that into a LINQ XML document and begin iterating it. We call a method that loads these into the assembly space and adds them to the list of assemblies. I add all of the assemblies first because I want to make sure any dependencies are already loaded before I start putting the parts into the MEF catalogs. Otherwise, MEF will choke if I try to add an assembly that references another assembly that hasn't been parsed yet. You can see how I take advantage of the existing MEF catalogs: for each assembly, I simply call the GetTypes method, pass those into a TypeCatalog, and add it to the aggregate catalog. When MEF asks us for the parts, I simply tell the aggregate catalog to pass along its parts. Take a look at this main loop:
private void _ProcessXap(Stream stream)
{
var manifestStr = new
StreamReader(
Application.GetResourceStream(new StreamResourceInfo(stream, null),
new Uri("AppManifest.xaml", UriKind.Relative))
.Stream).ReadToEnd();
var deploymentRoot = XDocument.Parse(manifestStr).Root;
if (deploymentRoot == null)
{
Debug.WriteLine("Unable to find manifest for XAP {0}", Uri);
if (DownloadCompleted != null)
{
DownloadCompleted(this,
new AsyncCompletedEventArgs(new Exception("Could not find manifest root in XAP"),
false, null));
}
return;
}
var parts = (from p in deploymentRoot.Elements().Elements() select p).ToList();
foreach (var src in
from part in parts
select part.Attribute("Source")
into srcAttr where srcAttr != null select srcAttr.Value)
{
_ProcessPart(src, stream);
}
foreach(var assembly in _assemblies)
{
try
{
_typeCatalogs.Catalogs.Add(new TypeCatalog(assembly.GetTypes()));
}
catch (ReflectionTypeLoadException ex)
{
Debug.WriteLine("Exception encountered loading types: {0}", ex.Message);
if (Debugger.IsAttached)
{
foreach (var item in ex.LoaderExceptions)
{
Debug.WriteLine("With exception: {0}", item.Message);
}
}
throw;
}
}
Debug.WriteLine("Xap file {0} successfully loaded and processed.", Uri);
if (DownloadCompleted != null)
{
DownloadCompleted(this, new AsyncCompletedEventArgs(null, false, null));
}
}
So how do we process the parts? The AssemblyPart provided by the framework takes care of it for us, as you can see here:
private void _ProcessPart(string src, Stream stream)
{
Debug.WriteLine("Offline catalog is parsing assembly part {0}", src);
var assemblyPart = new AssemblyPart();
var srcInfo = Application.GetResourceStream(new StreamResourceInfo(stream, "application/binary"),
new Uri(src, UriKind.Relative));
lock (((ICollection)_parts).SyncRoot)
{
if (_parts.Contains(src))
{
return;
}
_parts.Add(src);
if (src.EndsWith(".dll"))
{
var assembly = assemblyPart.Load(srcInfo.Stream);
_assemblies.Add(assembly);
}
else
{
assemblyPart.Load(srcInfo.Stream);
}
}
}
Notice I am locking on the main list to make sure I don't load a duplicate.
That's it - now we can simply pass one or many of these catalogs to the composition host and we're good to go (basically, take a look at any examples that use the deployment catalog and use this in its place).
Now once the user has the application, they can run it offline even though the modules are dynamic. Of course, you'll have to download all modules first - you can put a check to see if it is running on the desktop and force a download to make it happen. It will also automatically check for new XAP files when going back online, so you can release updates to modules independent of the fully composed application.
I don't have a project example for this but hope I've provided enough source for you to piece together the catalog yourself and take advantage of it in your Silverlight OOB applications.
