. . . or how I learned to stop worrying and love .NET 3.0.

There has been a petition out for a while asking for the reversal on the decision to move from WinFx to .NET 3.0. I’ve been kind of busy, but it has been bugging me that I haven’t mentioned this, so here goes.

I have blogged on the change and have requested for decoupling .NET 3.0 from the release of Vista (here and here). This latter point is a bit different from the petition where it is being requested to go back and decouple WinFx from .NET.

In my previous posts I come around to not caring what it is called and hoping that Microsoft will not bring us back to those “good old days” when there was no hope knowing what versions of Visual Studio 6 was installed.

So, here are my responses to the petition:

1. Future versions – .NET has defined a very solid convention for version numbers: major.minor.build.revision. Major version increments indicate structural changes; minor version changes indicate breaking changes. .NET 3.0 is neither a major or minor version change – it’s not even the same product. Future CLR improvements and API improvements will have the same interlocking naming. Worse, at this rate, the more significant CLR updates will be given the “.5″s while the “additive” (non-breaking) changes will have whole major versions.

This is an assumption that there was any commitment to the predictability of the .NET numbering scheme before this change; well two points define a line in three points define a plane, to three versions define a numbering scheme?

2. “Bootstraps” – .NET 3.0 does not have a “bootstrap”. It offers libraries that provide functionality as needed (just as it’s always been for .NET applications), but the “bootstrap” is in fact the .NET 2.0 CLR; “.NET 3.0 applications” merely make use of its libraries. Not only is this misleading, it impairs the modular paradigm of the .NET Framework. In terms of “kernels” and “bootstraps” as in the Channel9 video, the microkernel structure of the .NET Framework has been traded for a monolithic kernel.

I agree with that.

3. WinFX is an API, not a platform – Admit it. There are very good reasons that this distinction is made, namely that they are developed on separate schedules and are different things altogether. Though you express concern that without the version number increment it seems as though the platform has not improved, this is an invalid concern because a) .NET 2.0 is less than a year old; b) it is a lie to say that the platform itself has advanced.

WinFX may not yet be a platform, but that had always been the idea: WinFx was supposed to become the platform on which all Windows development space. So I think, we should give Microsoft some leeway on this one. The Microsoft Windows platform has in fact advanced a great deal.

4. WinFX is a better name – The name “WinFX” is more indicative of advancement and innovation than “.NET 3.0”. Furthermore, even though .NET 3.5 is where the real meat of changes to the framework stands, due to the previous major version number change, 3.5 is now a minor version change. This does not reflect the major additions that .NET 3.5 makes. Future versions will suffer in impact due to this change as well.

Pure opinion that WinFX is a better name. Odd that this is in a petition. In regards to what this means to .NET 3.5; would call in the next version .NET 4.0 solve this problem?

5. Non-Win32 (Microsoft and non-Microsoft) implementations – Other implementations of the .NET Framework, such as the Compact Framework, SPOT OS, Singularity and Mono will suffer from naming confusions. The CLR team took very, very careful steps to make sure the .NET Framework works on other platforms as well. Mangling the .NET framework with Win32 specific API breaks that, isolating the entire framework to Windows.

I agree that this is a problem, but one easily dealt with. As long as the .NET BCL (whatever version) continues to be portable, then the problem is solved. I do need to point out, though, that .NET 1.1 contains a whole Microsoft namespace that is not portable, so this isn’t really met today anyway. All that said, I do agree that convolving .NET 3.0 and WinFx makes this more confusing for Non-Microsoft implementations.

6. Where’s the “3”? – The current versions of all implementations will be stuck at .NET 2.0; the next version will be forced to be called .NET 3.5 even though the “3” portion is absent on non-Win32 implementations.

And why does that matter?

7. Explanatory confusion – on learning to program in C#, with the older naming, one can learn C# (2.0), and learn WinFX for Windows programming. Now, with .NET 3.0, one will have a hard time understanding why he needs to buy a C# 2.0 book that teaches .NET 3.0. In otherwords, it forces all .NET books to be updated and reprinted needlessly. Also, how are companies to “decide” what to use?

Artificial. C# was in version 1.0 until .NET 2.0, not “1.1”; and this was basically chance. There is/was no gaurantee that the C# language (or any other language) for that matter would move along with the .NET versioning scheme. The line “force all .NET books to be updated and reprinted needlessly” makes me chuckle. Why?

8. Merit – You justify the move chiefly by explaining the installation process. However, this does not add any value to the installation process. WinFX, ultimately being a library of .NET classes that can be installed to the GAC just like any other, is best installed by a normal installer like DirectX.

OK, you have me here. I don’t think there is any merit to this change from a practical perspective whatsoever. None. Zilch. I do think, though, that there is some merit in the marketing message: .NET 3.0 is how you develop on Windows. Period.
Look, versioning is a bitch. Naming is too. This is made way harder with a system containing lots of different components, and the WinFx name change is just a part of it.

I’m OK with it. Let’s move on.