Wow – I am really happy about all the feedback we have received on Soma’s blog about the name change from WinFX to .NET Framework 3.0!   I feel very lucky to work on a product that people care so passionately about.  

 

As you might guess, this decision was one we discussed at great length in internally... I wanted to share some of the discussion from my point of view...

 

For me, this debate started years ago, before .NET Framework 2.0 (aka “Whidbey”) even shipped.  I was working on pulling together the developer platform story for Longhorn (which would later be named Vista) and it was clear at the time that what we wanted to do was to make a compelling, coherent developer platform that was logically the successor to the .NET Framework 2.0.   While much has changed sense we embarked on this project, that underlying goal has remained steadfast.  Converging on the name .NET Framework 3.0 highlights this connection.   

 

While the .NET brand has a bit of a sordid history to it as many of you pointed out, the first product to ever get the “.NET” moniker was the .NET Framework and by far the clarity we have on the meaning of “.NET” with in the developer community is the most apparent.  Customers tell me that they know .NET implies a managed programming model that is core to the platform.    Just do a search for .NET in your search engine of choice and see for your self.  There are websites, blogs, magazines, and even books about “.NET”.   

 

Some of asked why we don’t do a completely side-by-side release of .NET Framework 3.0.  While this would avoid the “.NET Framework 3.0 includes .NET Framework 2.0” issue it would create a much bigger problem around deployment of the .NET Framework.  We have just released .NET Framework 2.0.  As such OEMs, corps and ISVs are still in the process of rolling it out.  Shipping another side-by-side release forces another parallel rollout even before the first one is finished.  By packing the new, compelling innovations in .NET Framework 3.0 the way we have, we make it easier to deploy just the delta in functionality without any worry of breaking existing applications. To be explicit, if the .NET Framework 2.0 is already on the box then the install of 3.0 only lays down the new assemblies.  This gives you a very high level of confidence that installing 3.0 will not break any existing apps AND it makes the install size and install time much, much better than a full side-by-side release would be.  In addition any machine with .NET Framework 3.0 installed (for example all Vista boxes) automatically run all existing .NET Framework 2.0 apps with no app-compat concerns.  For what it is worth this is exactly the model that Windows Server 2003 “R2” uses to release new functionality on top of a stable base.  

 

I have also read a number of comments about the version number “3.0” rather than “2.5” or “2.9”.  The general logic seems to be that the major version number should be tied to the version number of the base CLR engine.  Having worked on the CLR for many years, I can tell you I am very sympathetic to that argument, in fact it was the first proposal I put forward.  The main reason I changed my mind on this was observing where the degree of rapid innovation will be for the next few years.  It is going to be in the framework stack rather than the base engine.  I didn’t want to end up with version numbers such as 2.5, 2.75, 2.87.5.   While we are doing amazing innovations at the CLR level, they are going to take a bit longer to bake and I don’t want to freeze our top level version number during that time.  

 

So, what do you think?