Trimming .NET

As I mentioned in a previous post, Silverlight 1.1 will have the CoreCLR component in it to provide a subset of .NET support to control WPF/E (as an alternative to JavaScript, which is available in the currently released Silverlight 1.0). Since David asked “how you go about selecting which parts of .NET (which is huge) you decide to port to the CoreCLR framework you are developing,” I ended up having to do a little research.

I joined the CLR team in August of ’06, and the work to “trim” the desktop runtime engine and frameworks down to the for-use-in-Silverlight CoreCLR runtime engine and frameworks had already been completed. Back in June(!)¹ I talked with Jonathan Keljo, who was the program manager working on this problem, about what went on during this period.

Ultimately, we cribbed. Instead of trying to figure out for our (CLR) selves, we ended up looking at the pre-existing product that was already a slimmed-down version of .NET: the Compact Framework². We looked at their surface area and decided to see if we could match theirs. They had foregone features, and we chose similarly. One of the many ways CF manages size changes is just limiting the number of convenience functions.

When we prototyped the CoreCLR surface area, we ripped out some stuff based on instinct–what were the biggest (in terms of data and code size) features? We took out the top few (fusion, COM Interop, server GC, debugging support³), and strangely enough, we were close to our size goals.

On the framework side, we had inherited some subsetting already from the Rotor project. Since the platform adaptation layer (PAL) did not support all of the APIs we were calling in Win32 in the desktop version of the CLR to support some managed libraries, some of those managed layers were removed. In certain cases, we expanded upon the pre-existing PAL. The PAL had been written to be simple and very cross-platform, but knowing we wanted to support the Macintosh, we could supplement it with Macintosh-specific implementations of certain important APIs so as to not have to overly subset.

It’s not the cool-use-of-advanced-software-refactoring-principles answer I might have wanted, but it’s reflective of the environment we often find ourselves in–partially constrained by our desire to leverage previous work, and partially enabled by that same desire.

--
¹Yes, I know I’m behind.
²I knew this was going to be a cop-out answer, which is why I waited for so long to post. Perhaps I’ll get a chance to interview someone from CF and figure out how they went about their trimming procedures.
³Debugging support isn’t so much removed from CoreCLR as split out from the main product so it can be downloaded separately as an SDK.