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

you know what *that* sounds like..

[k-zed]

Microsoft has just begun killing Mono.

(Think "oh, that implementation really looks like ours! you must have read it! here's a lawsuit for you")

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

[Jugalator]

They could already have done this if they wanted to though.

(see also Lutz Roeder's popular .NET Reflector software)

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

[apathy maybe]

Really?
You have one person read the source, document it and put the documentation online somewhere.

You have second person read documentation and re-write functionality of code.

ReactOS does this exact same thing to re-implement the Win32 API, except that they have to 'break' the executable files. (My memory is shot, I can't remember the term for this, or the process as a whole...)

So long as the documentation does not contain source, merely what each function does, and so long as there is no obvious link between the two persons, there should be no problem.

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#.

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

[Ash-Fox]

Why not just have the developer read the .Net MSDN docs for the .Net API. It's not like anything they are doing is extremely complicated.

Because the MSDN documents are not accurate. Many times I found the API documentation do not contain the true behavior of certain APIs. This is one of the reasons why Wine requires testing API functionality on Windows first instead of just basing it all on the MSDN documentation.

NOT open source

[LarsWestergren]

A few months ago, we discussed Microsoft's intention to open source the .NET libraries.

Yes, and as one of the first posters pointed out, unlike Java for instance, this is NOT being published under an open source licence, Microsoft even says so. So why do you keep using the term?

Re:NOT open source

[Coryoth]

...to develop software that has "the same or substantially the same features or functionality" as the .NET Framework ; as long as it's still on Windows...Very obviously a "back off!" clause for Mono and dotgnu. Which is sad really. Only Microsoft could see such a requirement as good, and herein lies the problem of the monopoly. Ultimately .NET is a (relatively) nice programming framework and set of libraries, and were it developed by anyone but Microsoft they would welcome attempts to expand it's availability. Pretend .NET was developed by a small company that had focussed just on the Windows platform. If they were going to open source the libraries, the first thing they'd be doing is ensuring license compatability with Mono so they can expandtheir market. Hell, look at anyone other than Microsoft who do .NET stuff, like Chrome, or the .NET compiler for Eiffel: they both put in significant work to try and make sure they work with Mono (I believe the Eiffel guys actually have active discussions with the Mono team). In any sane world this would be the thing to do, it's only in Microsoft monopoly land that these sorts of license restrictions make any sense whatsoever. Which really shows you some of the ways the MS monopoly is holding the industry back.

Yay!

[4D6963]

Can't wait to see the best bits of it on The Daily WTF! \o/

It's in the source!

[nighty5]

Too bad the library is written in VB....

Reflector

[Anonymous Coward]

Of course, anyone doing serious development with .NET has been looking at the source for years now in any case by using Lutz Roeder's .NET Reflector, which is a C# (etc) decompiler (not just a disassembler). It's the only way to reliably discover and work around the horrible bugs and misdesigns in MS's libraries. (Yes, WSE, I'm looking at you.)

Reflector is downloadable from http://www.aisto.com/roeder/dotnet/. And it's obfuscated, so it won't run usefully on itself :-)

Looks rather clunky

[Dr_Barnowl]

Has anyone looked at the instructions for using these sources in Visual Studio? It seems monstrously crippled compared to debugging third party sources in Eclipse.

  * Each source file you debug into is dynamically downloaded once for each session and not retained.
  * Setting breakpoints in the source is a multi-step process, because the source is different from the corresponding symbol files because the copyright banners they insert change the CRC. You have to tell the IDE to ignore that.
  * You have to manually tell it to load symbols for each file.
  * The symbols are also served up from an MS server (but they are cached beyond a single session).
      * Some of these symbol files are 10MB, so VS "may be unresponsive" while you download them.
  * "Go to Definition" doesn't work.

This in contrast to the same support in Eclipse, where all you have to do is
  * Download the source
  * Tell the IDE where to find the source

14) Can I point a web browser at the symbols URL and download the symbols directly?

No, you'll get an HTTP 400 (Bad Request) response. So in addition, you'll need a professional version of Visual Studio, because the Express versions don't support the Source Server feature.

Given that it all seems so inconvenient to use, I think I may be sticking to Reflector.

it's not open source

[nguy]

Microsoft is not releasing those libraries as open source. What they are doing is what they and other companies have been doing for a long time: releasing some of their source code in read-only form to "help" people debug.

In fact, the real problem with this is that, in case of ambiguities, people will code increasingly to Microsoft's source code instead of the specification. Furthermore, after having released it, Microsoft may attempt to claim that the Mono project copied some of their source code in violation of the license.

One can't prevent Microsoft from doing this, but it's not a good thing.

Not everything is about you

[Anonymous Coward]

This release is not intended to benefit the Slashdot crowd. Of course it isn't "open source", and Microsoft never said it was. This is Microsoft assisting developers working with .NET on the Windows platform. There are a huge number of developers who fit that description. Sorry if you don't, but not everything is about you.

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.