Microsoft Releases Source of .NET Base Classes

Disgruntled Fungus writes "A few months ago, we discussed Microsoft's intention to open source the .NET libraries. According to a developer's official blog, the source code is now available. The source to libraries such as System, IO, Windows.Forms, etc. can now be viewed and used for debugging purposes from within Visual Studio. Instructions for doing so have also been provided. The source code has been released with a read-only license and 'does not apply to users developing software for a non-Windows platform that has "the same or substantially the same features or functionality" as the .NET Framework.'"

Comments

Re:you know what *that* sounds like..

[Nurgled]

It is correct to say that .NET Reflector is a decompiler. It just happens that IL (the bytecode that .NET languages compile to) is quite high-level, so it's much easier to turn IL into readable C# code than it is to turn x86 machine code into C. .NET assemblies also carry a lot of metadata along with the code, allowing Reflector to find the namespaces, classes, properties and methods without needing the original source code. Reflector itself also does some other magic when possible. For example, it can read in the debug information that the C# compiler can optionally produce (the .pdb file) and use that to fill in the things that you can't find out from the assembly alone.

An interesting (for some values of "interesting") exercise is to take some VB.NET code, compile it and then use Reflector to view it in C#. Since the two compilers don't generate completely equivalent code, you can get some unexpected results. A good example to try is some VB.NET code using late binding of methods on variables of type "Object", which isn't a language feature in C#.

The Source for the Runtime is also out.

[aldousd666]

The CLR 2.0 source (the runtime, not just the BCL) code is up too, it's in C++, not managed code. Strangley the article and summary seem to completely miss that fact. I'm very surprised, because it's much more significant, and it can't be ascertained using the decompilers like the managed code can. THIS is probably the thing that can kill mono.