WinFX 3.0 Renamed .NET Framework 3.0

Jason,

Thanks for clearing things up, it helps quite a bit :)

Honestly: I'm not sure how I feel about this. While I think it certainly makes sense (and love that you'll now be installing it where it should've been all along), it seems like the way you're versioning stuff now is certainly confusing. Just the simple fact that now the framework version number doesn't match the runtime and compilers version numbers (at least for C#/VB) is sure confusing.

Also, I was under the impression that Orcas would force a new .NET Framework upon us, so if that is true, does it mean that we'll get *yet* another .NET Framework/Runtime version at that point? (or worse yet, end up with .NET Framework 3.0 with CLR 2.5 and Compilers 3.0?)

Bueno, dicen las malas lenguas (Jason Zander General Manager del .NET Framework) que se va...

Out of curiosity, what happens to Windows 2000 support?  Im guessing dropped.

I wonder why the jump to 3? why not 2.5 or 2.1? A major version number shift suggests to me new foundation (ie, new runtime features -- like generics), whereas adding to the set of available classes seems a bit more like a minor increment, even if those classes are significant.

My basic question is -- are you versioning the runtime or the class library? Both?

It seems you are trying to version two different things under one numbering scheme. The library and the runtime. I suggest developers can understand this situation, and would accept separate versioning. And as the runtime becomes more stable, it does not make sense to keep shipping it with every increment of the library.

I think the ideal situation would be independent runtime and class library version numbers.  Each major operating system version would come with some pair of runtime and class library. Then developers would have a simple versioning system that makes targeting easy. (all Vista users have 2.0 runtime, 2.0 library, then Vista+n has runtime 2.5 and library 3.8) If I want to deploy a fancy feature that depends on runtime 2.0 and library 4.0 onto fresh vista machines, I would only need to install the library.

Such a system allows that you might want to add features to the library which require a particular runtime. fine! once in a while you want to add library classes without changing the runtime (winfx). fine!  

Versioned assemblies take care of DLL hell, but now we are stuck with framework hell.  

My suggestion for framework versioning:
Slow runtime version cycles and focus on library improvements like winfx. Save framework changes for OS version increases (or a similar time-scale).
when targeting a class library that is *newer* than the target runtime library, statically link the newer classes into the compiled assembly. This way the assembly will be compact, complete, and will run on any runtime. Since the time between runtime releases will grow longer, we get less headache. And the problem of ballooning assemblies is manageable, since compiling to target the next runtime version will change any static links to dynamic links.

I don't know about 3.0, maybe 2.1. My understanding is that WinFx is built on 2.0.

What is "orcas" going to be 4.0?

<script>windows.alet("This could be a cross script acttact");</script>

You say that LINQ is in the Orcas product. LINQ is a compiler extension. New Compilers have always been part of new .NET Framework versions, not Visual Studio. Will this change?

This is just a big mess. Why not go with .NET 2.1?

If you like to get comments - here is mine:

I really like .Net as a development platform, but this is one of the  most stupid ideas ever (and there were quite some stupid ones). I'll tell you why:

1) WinFX simply isn't ready to become a core component of the platform! Hell - the .Net Framework is the CORE for most of modern Windows development and it needs to be STABLE (I don't mean no crashes, but be reliable for developers and be around for years without significant changes).

2) WinFX is FAR from being ready. It contains TONS of showstoppers (see point 1) that are said to not be fixed for "v1" (like Window being a Visual but not even remotely behaving like a visual, ignoring Transparency, Opacity and so on). It is ABSOLUTELY unacceptable to put something that is so extremely unfinished and volatile into the VERY CORE of the platform.

3) Because of the above reasons lots of developers will not use WinFX for a period of time, but they will have to ship it with their apps. And the downloadsize of the .Net Framework 2.0 is already quite hefty. Integrating the three components into the core will most likely TRIPPLE the download size and use hundereds or Megabytes to install.

You should release it as an external addon as it was and integrate it into the Framework as soon as it becomes somewhat stable (maybe v2, more probably v3).

Replacing a part as big as Windows Forms is already a bummer that should never have happened in the first place, but replacing it with a technology that will itself be significanty changed to the next version *AGAIN* will drive TONS of developers AWAY from .Net - as far away as possible, because this is just a slap in the face of every developer using .Net.

Doing a clean cut and developing an entirely new platform with .Net instead of Win32 was a good move, because Win32 was about 15+ years old and seriously outdated but you simply cannot do that every two or three years or you will be out of anybody developing in just about no time.

Jason Zander (General Manager, .NET Framework) answers some questions about the decision to rename the...

Does this mean there will be no "Vista-only" parts in .NET 3.0?