A little early Christmas present for everyone. ;-)
What's in it?
The installer includes the binary, the docs, and a new Silverlight version of our Stoplight quickstart (and no, I didn't port the event broker, anyone want to give it a shot?)
Probably the biggest difference is that Microsoft.Practices.Unity.dll for Silverlight is contained in a single assembly. We've merged the previous ObjectBuilder2, Unity, and StaticFactoryExtension into the one DLL. This resulted in a slightly smaller overall package and a lot more convenience when referencing the container, since you don't have to hunt for multiple DLLs when adding references.
One thing that's not included is the XML configuration assembly, Microsoft.Practices.Unity.Configuration.dll. There's a simple reason for that - Silverlight doesn't support System.Configuration. We'll have to come up with a new configuration file story. I'm toying with some XAML based ideas on this front, but it'll be a while.
Also, the recently released interception mechanism (Microsoft.Practices.Unity.Interception.dll) hasn't yet been ported, so that's not included either. We'd like to include it going forward, but it'll take some work to it working and we didn't want to delay the release.
The container basically performs the same in Silverlight as it does on the Desktop CLR. The container API is identical. There is one minor gotcha: due to the difference in security model in Silverlight, you can only resolve public types through the container. The desktop version lets you do public or internal.
How'd we do it?
Luckily, the Silverlight environment really is very close to the Desktop CLR. It was mainly a case of pulling out references to things that Silverlight didn't support. We'd already started down this road with some work done in version 1.2. Replacing calls to methods that didn't exist on Silverlight with ones that did, for example. I did have to tweak a couple of source files (for things we missed) but it didn't affect the overall code any.
In order to do the port, I started by creating an empty Silverlight project. I then imported the Unity source files into it, and then let the compiler tell me what stuff didn't work. Yes, I'm lazy that way.
The vast majority of the code works for both desktop CLR and Silverlight. There were a couple cases where we needed environment-specific code. Looking at the source, you'll see a few files with the .Desktop.cs or .Silverlight.cs extensions. These are how we marked up the code that was specific to one platform or the other. The .Silverlight.cs files are only included in the silverlight project, and the .Desktop ones are specific to the desktop project. For classes that needed to be tweaked, I used partial classes, with the partial parts in a platform-specific file. The various custom exceptions are probably the biggest example of this. On the Desktop CLR, exceptions should have a serialization constructor and be serializable. Silverlight doesn't support this. So each exception class is a partial class. The serialization details are in a .Desktop.cs file. The Silverlight project simply omits those files and we're good.
The unit test suite has also been ported, and uses the same approach. Not every test from the Desktop suite is included, of course. We excluded everything having to do with configuration, for example (which turned out to be rather a lot of tests). Taking advantage of the very nice Silverlight Unit Testing Framework made it pretty easy to reuse our existing VSTS test suite in the Silverlight environment.
That's up to you! If you're working on a Silverlight project, please download and let us know what you think! What's important for you? Now's the time, as we're currently prepping for the next version of Enterprise Library and Unity.