Software Mechanics
Why do we even have that lever?

Unity and Silverlight: It can be done!

April 9, 2008 10:33 by Chris

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!

Currently rated 1.6 by 34 people

  • Currently 1.558824/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Categories: p&p | Silverlight | Unity
Actions: E-mail | Permalink | Comments (17) | Comment RSSRSS comment feed


Comments are closed