Moonlight's 2.1 profile

Silverlight comes with a shrunk down version of the CLR called the CoreCLR and also comes with a reduced version of the core class libraries.

Silverlight uses a subset of the 2.0 API and removes a lot of stuff that would only be used on a desktop or a server and removes overloads that people are not likely going to use and according to some blog posts even things like System.Collections will be removed giving preference to the generics-based API in System.Collections.Generic.

Nice graphic showing my Inkscape skills:

To support this "thin" profile in Moonlight we had a couple of choices.

We really did not want to branch our source code and chop code left and right until we removed all the extra baggage. We also did not want to use compilation defines because that would get ugly very fast.

Instead what we did was productize Linker tool that was developed as part of the Google Summer of Code last year.

The Linker could take an assembly and a description of the desired API entry points and produce a new assembly that only contains the requested entry points plus any of its dependencies. Although the Linker from last year was able to do some basic linking, but as with all software projects, the devil is on the details. JB has been working on productizing the tool ever since he joined Novell back in May.

The idea was that we would feed the linker a superset of our 2.0 library (2.0 plus the handful of Silverlight-esque APIs) plus a linker description file, and it would produce the resulting Silverlight compatible assembly.

The above approach allowed us to minimize the number of ifdefs that were required in the source code. In addition to the linking stage we also needed a way of inject a number of security attributes (again to avoid having a mess of ifdefs everywhere).

So JB created new specialized tool that allows us to add, remove and validate assemblies. We call this the Tuner. Both the linker and the tuner are based on Cecil a library for handling CIL files.

The tuner can do most of the heavy lifting, but there are a couple of areas that still required human intervention:

• In a handful of cases abstract methods are no longer exposed in Silverlight, we had to work around this directly (XmlReader).
• In a few cases there are some interfaces and class hierarchy changes required, those also had to be done manually.

Finally, since our C# compiler depends very strongly on its mscorlib (the reason we have 3 compilers today, one for each profile is linked precisely to this dependency on mscorlib) we had to add special support to the VM to allow the compiler to call into methods that we had hidden as part of the tuning process.

This afternoon for the first time JB was able to build the 2.1 profile from the start up to the Silverlight support libraries and the Silverlight plugin with the tuned assemblies.

Although we have been debugging Moonlight with 2.0 assemblies for the past few months due to some of the API changes some applications like the SimpleXPSViewer did not work.

There is still some work left to do as you can see from the warnings generated by the tuner, but we are getting there.

Silverlight Toolkit

With the 2.1 profile in place it is now possible for people on Linux and MacOS to develop Silverlight applications without using Windows.

The bad news is that the 2.1 profile will not be available in Mono's 1.2.5 release as we branched that release a few weeks ago. So developers interested in doing Silverlight development on Linux or MacOS will have to wait until our 1.2.6 release in a couple of months.

In the meantime Ankit has added support to MonoDevelop for compiling existing Silverlight VS Solutions as well as generating Unix makefiles from the VS solution file. You must be using an SVN release of MonoDevelop (sadly, 0.15 wont do it). for this to work though:

bash$ mdtool generate-makefiles SilverlightAirlines.sln --simple-makefiles
Creating configure script
Creating rules.make
Creating Makefile.include
Adding variables to top-level Makefile
Makefiles were successfully generated.
bash$ 	
	

The default is to generate auto-tools based makefiles. It is recommended that people with acid reflux, ulcers or other delicate stomach conditions use the --simple-makefiles option. --simple-makefiles produces a configure and Makefile script that are essentially the labor of love.

If we can sort out the license for the Silverlight.js template, we should also be able to ship MonoDevelop templates for creating Silverlight content.