(Whew, I didn't realize I'd gotten so far of the blogging wagon. Time to hop back on!)

At the last Seattle Code Camp, I ended up talking with David Starr for quite a while. He apparently thought I knew what I was talking about (shh! Don't tell him the truth!) and invited me to be a guest on the Elegant Code Cast. It was a great talk about EntLib, life in p&p, Unity, and all sorts of other stuff.

The episode is available here. Thanks again, guys for the great chat!

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?)

What's different?

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.

What's next?

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.

Today was our weekly "slack time" day, where I get to go sit in a conference room and experiment with new technology. Today I did this:

Yep, got Unity running under Silverlight 2.0 beta 1. In the end it took me less than four hours (at least 30 minutes of which was waiting for the SDK to install and the obligatory xaml designer crashes). I made a couple boneheaded mistakes  in the project files, so I'm not going to post sources just yet.

Here's an overview of the porting process:

• Install 2.0 Beta 1 plugin, SDK, Unit test tools and project templates.
• Create a new Silverlight project.
• Create Silverlight libraries for ObjectBuilder and Unity.
• Copy the source for full OB, Unity, into the new projects. Add the files to the project.
• Compile, fix errors, compile, fix errors, ... etc. ;-)

 Here's the issues I ran into.

Standard binary serialization is gone. As a result, the SerializationInfo and StreamingContext classes are not available. This is an issue because FxCop insists on the four standard constructors on every custom exception class. In Silverlight, there are now THREE standard constructors, not four. So remove them from all the custom exception classes.

The existing code uses methods like Array.Find and List<T>.RemoveAll. Many of these methods were removed from the Silverlight version. So I replaced them with the equivalent Linq expressions. This actually made some code a lot easier to read, which is nice.

System.Configuration and everything associated with it doesn't exist, which involved removing a bunch of stuff from the unit tests. My fault really, they should have been in a separate fixture to begin with.

The IL generation stuff is actually supported on Silverlight, which pleasantly surpised me. I did have to make one change though. When generating the build plan, we have some code that checks to see if you're in full trust, and chooses where to host the dynamic method based on the trust level. This way, in full trust we can do injection on internal or private classes. In Silverlight, you can't do this, and you can't choose where to host your dynamic methods anyway. The net result is that set of code goes away, and we just accept that you can't inject non-public stuff in Silverlight. Unfortunately, that meant changing a bunch of stuff in the test code, as lots of the tests have private nested classes as test subjects. Had to go through and change them all to public, and it worked.

One really weird thing I ran into is in the StagedStrategyChain class. This class takes an Enum, and uses it to determine how many stages the chain has. To figure out how many stages are present, we called Enum.GetValues(), which returns all the enum constant names. Guess what? This method is gone in Silverlight. I cheated by just looping up from zero to find the highest value defined by the enum; it's grotesque, but it worked.

One thing I'd like to throw in: I really, really appreciate the creation of the Silverlight unit test fixture. It would have taken a LOT longer to figure out if this thing was working without it. And since the SL runner is source compatible with the MSTest stuff, I just copied my existing tests in and they just ran. Very, very cool! 

I'm not going to be posting this code just yet, for a couple of reasons. The first is that the project isn't good enough yet; I really need to reorganize the solution I have right now, for example. The second reason is that this is NOT a supported scenario, and I don't want to give the impression it is. So you'll never see this on the Unity codeplex site, for example. Maybe it could be put on UnityContrib eventually?

Anyway, just wanted to let folks know it's not only possible, it was actually pretty easy!