Last December I created a small utility to reduce the size of XAP files for modular Silverlight applications. It served my purpose at the time, but more recently I've been using the tool in the context of a new application, which revealed a problem related to localization. In some cases the application could crash because of satellite assemblies that are embedded into the XAP files.

The new version takes satellite assemblies into consideration: they are removed whenever the main assemblies is also removed. There are a small number of other issues that were fixed, like an incorrectly described command line parameter.

Even though Silverlight has fallen out of grace with the powers that be, there are still some companies using it today for entertainment or line of business applications. Particularly for that last category, modularity can be a powerful tool in creating a flexible solution.

Over the past few years, I've worked with modular Silverlight applications based on Microsoft Prism. Every module is it's own XAP file, which is loaded on demand by the framework. Over the years, people have also rolled their own lightweight modular applications, also making use of XAP files. This article is about a specific problem with building these types of applications: optimization of the total application download size.

Contents:

• Part 1: Explaining the Issue
• Part 2: Working on a Solution
• Part 3: Alternatives

Limitations

In hindsight to the created solution, there is an issue that cannot be addressed in this way: When a consumer fails to call Teardown properly at the right time for constructed objects, the DisposingSharedLifetimeManager will not behave as expected. For some, this may be a big issue, because it may not be very customary to bother to call Teardown when using Unity, precisely because it usually does nothing useful anyway.

Alternative Solutions Using Unity

One alternative is to use a wrapper of sorts and register that in the container instead. The usage would look something like this:

Contents:

• Part 1: Explaining the Issue
• Part 2: Working on a Solution
• Part 3: Alternatives

Two New Lifetime Managers

Having explained the issue, how can we solve it?

Before starting, I should mention that my implementation is based on previous work by Rory Primrose, who wrote an extension that changes the behavior of the TransientLifetimeManager in order to dispose of objects. He does an excellent job of explaining some of the rationale behind his implementation, so be sure to read his article.

I've placed the complete source code for my article (including some quick unit tests) on GitHub.

My approach is a little different: I did not want to change the default behavior of Unity, so instead I defined two new lifetime managers to explicitly set the desired behavior with: DisposingTransientLifetimeManager and DisposingSharedLifetimeManager.

DisposingTransientLifetimeManager

This lifetime manager behaves pretty much like the built-in TransientLifetimeManager; every time a new object is created. The only difference is, that on Teardown of any object, we will call Dispose() on objects that were created as a result of the original build-up operation (provided they are using this lifetime manager, of course).

Contents:

• Part 1: Explaining the Issue
• Part 2: Working on a Solution
• Part 3: Alternatives

Introduction

In modern software development, the use of Dependency Injection is a very important principle. It allows you to build large systems with properly decoupled and testable components. The use of Inversion of Control containers is a popular way of implementing Dependency Injection. If you are unfamiliar with these terms, this article probably isn't for you; I suggest you read Martin Fowler's excellent article about DI and IoC instead :)

In the .NET world there are probably dozens of different IoC containers available. They all serve the same basic need, but there are important differences in the features they offer. One popular IoC container is Unity, created by the Microsoft patterns & practices team.

Just because it's popular, doesn't mean Unity is perfect however. In this multi-part article, I will try to address some issues around classes implementing IDisposable in combination with Unity.

Earlier today, I blogged about a reusable behavior extension to make debugging Silverlight apps a little easier. I wrote most of that article months ago and in the meantime I've added a second behavior extension to support Silverlight software development. I included it with the download, but some explanation about its purpose might be in order.

If you're used to debugging ASP.NET web applications together with WCF services, you will know that Visual Studio automatically attaches the debugger to the service process in addition to the website. When you It doesn't do this for services being called from Silverlight. Instead, Visual Studio will probably warn you that the service call will fail, but we've taken care of that problem with the behavior extension from the previous post.

The solution is fairly obvious: you will have to make sure that the debugger is attached to both your web application and your service.

If you've ever developed a Silverlight web application in conjunction with WCF services, you have probably run into some challenges when it comes to debugging the solution as a whole. Silverlight applications are limited to using services from the same server and port number as the application itself, unless the service explicitly allows external access through a clientaccesspolicy.xml file.