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.'"

Because "Open Source" is a stupid term

[QuantumG]

To my bearded friends from 1998: great work making an already confusing term "Free Software" even more confusing by rebranding it "Open Source Software".. this is the result. I know, I know.. you considered a whole lot of different alternatives but nothing really struck the chime like "Open Source" but maybe we all should have looked a little harder. How about "Unrestricted Software". It makes even more sense today, what with DRM and all. And the BSD trolls can still have their arguments about what "unrestricted" really means just as they do now about what "free" and "open" really mean.

Re:it's not open source

[mrpacmanjel]

Absolutely agree!

You have to be *careful* how you use this.

Mind you what if you *do* discover a bug in Microsoft's code, what can you do?

You can't modify the source code - 'it's read only', even if you were allowed to to modify it you'll 'break' standards.

You can tell Microsoft - we all know how well they listen to 'customers/developers' and how long will it take them to fix it.

If you also use mono you will not be able to contribute to the project because you have seen 'the code'.

I've been using .net in a major project at work and as yet not needed to see the source code of the libraries (I probably never will) and I know there are bugs/'features' in the libraries but there are workarounds - it's not stopped us so far.

I really don't think it's in mono's interest to try and keep compatibility with Microsoft's libraries (it's that old Microsoft Treadmill routine again).
I imagine at some point Microsoft will release a future library that will make the current version obsolete - they are already doing this with the .forms library - just you watch!

Mono and it's developers have put in too much hard work for this to happen - mono should follow it's own path and develop libraries from the 'ground-up'(e.g. gtk#) rather than attempt to keep up.

We should have more faith in the mono project rather than constantly 'slam-it' for 'patent issues' or because Micorsoft 'invented' it.

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 [microsoft.com] (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.

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

[fleck_99_99]

Microsoft is actively working with Mono to make the "Moonlight" Linux port of Silverlight a reality.

Scott Guthrie blog post about this [asp.net]

"Over the last few months we've been working to enable Silverlight support on Linux, and today we are announcing a formal partnership with Novell to provide a great Silverlight implementation for Linux. Microsoft will be delivering Silverlight Media Codecs for Linux, and Novell will be building a 100% compatible Silverlight runtime implementation called "Moonlight".

Moonlight will run on all Linux distributions, and support FireFox, Konqueror, and Opera browsers. Moonlight will support both the JavaScript programming model available in Silverlight 1.0, as well as the full .NET programming model we will enable in Silverlight 1.1.