I know there are lots of people that probably already know this, but if you’re a .NET developer you really should download and take a look at the SSCLI aka ROTOR. The SSCLI is not just for CLR wonks to play around with. Although it does have a full CLR implementation the parts that interest me the most is the full source to some of the system base classes that are also included. Admittedly not all of the most commonly used namespaces are there, but some of my favourites like System.Xml, System.Text.RegularExpressions and System.CodeDom are in there. I can think of a number of cool little projects I’m going to undertake using this code. ROTOR is a great place to find examples of “production quality” C# code, and even though tools like Reflector do a great job of reconstructing code from MSIL it is usually much easier to read the actual code it’s self.
Update: I just thought I would include some info on resources in the SSCLI. The SSCLI uses strongly typed resource files (where each resource string value is a property accessible via it’s key). Apparently this is the way of the future since resgen.exe in the .NET Framework 1.2 (a.k.a Whidbey) has been expanded to create these resource class files also. The Whidbey version of resgen.exe uses the CodeDOM (and can output any language that supports CodeDOM). SSCLI (since the Base Class Libraries are written in C#) uses a Perl script called gensr.pl to generate C# classes. If you want to recompile parts of the SSCLI with minimal pain you will need to generate these resource classes either using the Whidbey resgen.exe or the Perl script. I have used the resgen.exe approach and it outputs “drop-in replacements” for the Perl files. I discovered this information here IIRR http://weblogs.asp.net/vga/archive/2003/12/26/45958.aspx
Something else that I should also mention about SSCLI\ROTOR is that Microsoft indicated at the PDC BOF that there would be a new SSCLI release forked off the Whidbey code base, released (hopefully) a short period of time after Whidbey is released. Joel Pobar has the details here. I think it is great to see Microsoft continue to support SSCLI going forward.
Comments
I dunno - if you feel that interested in seeing the source for a CLI - why would you want to limit what you can do with your knowledge in the future?
You may use any information in intangible form that you remember after
accessing the Software.
So I don’t think I am "giving up" a great deal.
I certainly think taking a look at the MONO source is a valuable thing, but the SSCLI BCL are very similar to Microsoft’s "production" BCL, and thus may be of more interest to .NET developers. For example if I’m writing a regular expression and want to see how it is parsed and run I can just change the namespaces in the SSCLI RegEx implementation, add it as a project and "step through" the source as it is parsed an evaluated.
http://www.123aspx.com/rotor/default.aspx
Cheers!
Dave