Origin of the Silverlight CLR and .NET Framework

One of the common questions I’ve been asked at Mix is exactly where did the CLR / .NET Framework in Silverlight come from? We actually started building this version of the CLR right after we shipped V2.0 in October 2005. The approach was simple: figure out the minimal required core that would allow a set of very common developer scenarios to be fulfilled. Size was of utmost importance and all feature contributions would have to be justified in the context of the scenarios and how much they cost us on the download. The other requirements included ensuring first rate performance and the highest compatibility bar we could get with the desktop CLR.

With this set of goals in mind, we started from the bottom up (quite literally). To keep up performance and compatibility, we kept the same core type system, garbage collector, JIT compiler, etc. This engine also includes all of the generics work added to the V2.0 release. The same approach was then applied to the .NET Framework libraries. Again the goal was simple: what is the minimal library support you need to build a compelling application. With this you wind up including XmlReader/XmlWriter, but not the richer object layers on top. Those are great features (and still readily available for you in the desktop .NET Framework). But we needed a small package. There were tons of debates and lot’s of tweaking over the last 16 months.

In order to get this done in a short time frame with high compatibility, we decided to start with the desktop CLR/NETFX. We did the factoring in that code base. In most cases, the Frameworks code is quite literally the same code from the desktop version. In other cases we kept the API signatures the same, but plumbed out the implementation on top of the browser support.

The result is a pretty small stack that still gives you superior performance and access to all your core features. We are using the same metadata / IL file format, same language semantics, etc. The real test came when we tried to run LINQ on top of the new stack and it just worked! That’s right, we took the ‘Orcas’ LINQ assembly and copied it over to run on this stack and started executing sample code. The cool thing about this is you can take a Silverlight application and your source code will be compatible with the desktop version of the .NET Framework. It is very easy at that point to extend the application to use more features of the desktop if you like. The key thing here is developer choice.

Scott Hanselman has an interesting picture on his blog of the various versions of the CLR/.NET Framework which is pretty accurate. ScottGu and I did a podcast for Hanselminutes this afternoon which covers a lot of this ground in more detail. I will post a link to that podcast when Scott publishes it.