Toward .NET Framework 3.0…

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? 


Comments (28)
  1. Keeron says:

    This was probably answered in the comments section of Soma’s blog, but wanted to get more details.

    ".NET 3.0" will not include the new C# / CLR improvements? (whats being called the C# 3.0, including the LinQ, Dlinq, etc functionality). Correct?

    What happens when you do release C# 3.0? Does the version of .NET framework get bumped to 4.0?

    Are there plans to merge the two SDKs now? (.NET 2.0 and WinFX). That is, just unify them and make them a single SDK. That might still be confusing, since you have Winforms and Avalon, but I guess thats just two different ways to present/visualize your data.

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

    I could not agree with you more there.  You hit the nail right on the head.  When all comes down to it, it’s important to keep releasing new features, even if it means that the core doesn’t have any.

  3. George says:

    Brad, just to elaborate a little bit on what you say… When it’s time for SP1 of the CLR 2.0, will the whole .NET Framework package receive version number 3.1, including the CLR version upgrade from 2.0 to 3.1, or will the CLR continue incrementing on the 2.X?

    The fact that actual deployment will not become an issue is great, but I think it is at least as important to escape the "versioning nightmare" when talking to people. A common version number for both CLR and the former WinFX would make people understanding each other much better.

  4. jvierra says:

    I agree.  If it can be possible to decouple the versioning and interaction between CLR and Framework deployment and maintenance could be made much easier.

    Since the CLR is about how the code is implemented and not "what" code is implemented, I would think that teh CLR should always upgrade without a need to upgrade the Framework.  The Framework may. at time, require a minimum CLR but should never have an issue with a newer CLR.

    I can take my old Ford and put a new Hybrid engine in it but I don’t have to replace the steering whell of the hubcaps.  I should be able to upgrade the CLR and still have the same functionality and compatibility in teh Framework theat is already in use.

    If the NET team can accomplish this to some degree we developers, admins and users will be very pleased.

    If you can succeed in completely decoupling all of the layers you will have accomplished something that I don’t believe has eve been done successfully.

  5. Philip says:

    My questions were answered since I posted ’em on Soma’s blog (seems many thought my questions were critical, but they weren’t meant as such!)

    The big problem I have with this is the sudden sea change in meaning:

    .Net 1.0 -> CLR, FCL, etc.

    .Net 1.1 -> CLR, FCL, etc.

    .Net 2.0 -> CLR, FCL, etc.

    .Net 3.0 -> Frameworks that run under .Net 2.0

    Before, applications required a specific version of .net (or, perhaps just *a* version of .net).   Lately, some needed WinFx libraries as well.   Now, however, we will see:

    "This application requires the .net framework 2.0 runtime and .net framework 3.0 frameworks"

    I guess it seems analogous to biztalk shipping a bunch of new adapters and calling the package BizTalk 2007 (requires BizTalk 2006).  It’s not a new server, just new features.  

    Hopefully this all reconverges soon (I assume it will – I have faith), and will turn out to have been a good idea.  But please don’t tell us this is to "reduce confusion" – that’s like when signs tell you that dumb rules are "for your convenience", or when telemarketers need personal information "for security reasons".  

  6. Dennis says:

    I still don’t get it.

    Why needed WinFX a name-change in the first place!? Don’t start with "there was much confusion"!

  7. Chris Nahr says:

    Brad, I think you meant to say that the .NET brand has a "sordid" history, rather than one that’s ordered alphabetically. 😉

    On topic, the combined deployment of .NET 2.0 and the new libraries is good, and so is the differential installation. But what does that have to do with the _name_ of the whole deployment package? Why couldn’t you do this while still calling the package WinFX?

    Also, what exactly are you planning to do when the CLR and the compilers change while Avalon and other new libraries stay the same? Will you force us to deploy the whole gigantic mess all over again because it’s then called ".NET 4.0" and needs a new target directory, even though many of the libraries haven’t changed at all?

  8. Jonathan Kaufman says:

    I am still unsure of the motivation for change. This just seems more confusing. I thought everyone was comfortable with the WinFX moniker. There needs to be a clearer way to define what is what. After reading both your blogs my question is what is the .NET framework now? What happens when CLR is updated? What happens when WPF, WCF, etc is updated? It seems previous posters have these same concerns. Please help us obi-brad-kenobi.

  9. Muhammad Mosa says:

    Does this mean a new version of VSTS? as I know every release of .Net Framework can only be used used with its correspondence VS.NET Release?

  10. Jon Townend says:

    mmmm… my two cents.

    Because of the way we had side by side with 1.0, 1.1, and 2.0, it would seem that calling this 3.0 is not right.

    Calling it 2.0 with WinFX would make more sense.

    Then you’d have some systems with 2.0 and some with 2.0 with WinFX.

    Seems simple enough to me. It creates more confusion with .NET 3.0 because it’s not .NEt 3.0, it’s .NET 2.0.

    Why call it something it’s not?


  11. ringi says:

    I work for an ISV, is it hart enough already trying to explain to our sales / support people and our customers what versions of each bit of software we need on a system to run.

    Having to explain that some of our software works with .NET V2 or .NET V3, but for other bits you have to install .NET V1 (we have not yet done new release since .NET V2 shipped so it has not been tested with V2) is not nice.

    I see WinFx as just being another add-on to .NET in the same way that some software needs IIS installed as well as the .NET framework, others will need WinFX as well as the .NET framework.  We are not planning on using WinFX for a few years, as we still have a lot of customers on Windows 2000.  The name change means that I will have to spend time answering questions on it every time someone read about it somewhere, it is so match easier just to say we don’t need WinFX rather then having to talk about what version(s) of .NET we don’t need.

  12. RonO says:

    I have to agree with many of the other comments I’ve seen so far.  This name change/appropriation isn’t the way to go.  WinFX is an addon.  It should be treated as such.  Sure, the install for WinFX should include the Framework 2.0 install, but that’s as far as it should go.

  13. Bryant Likes says:

    This makes no sense to me. Can someone at Microsoft *please* get some control around the product naming? Is this name change just meant to distract us from the fact that we got such crappy names in the first place (WCF,WF,WPF)?

  14. Jeff Stong says:

    This is all over the Microsoft blogs: so if you’re following them you’ve no doubt already seen this (more…

  15. Thanks Brad but… Not to mention the CLR/libraries/language version mess, it’s still hard to equate WinFX with the whole .NET Framework. As RonO noticed above, WinFX looks like an addon. WinFX is great, awesome, and lots of us are looking forward to it – but it’s just a set of 4 cool technologies based on "old" .NET Framework 2.0, and all this cannot be named .NET Framework 3.0 as release of a software product with an addon cannot increase its major version number. It’s a pity you’ve merged the terms.

  16. MattH says:

    Brad, as always I commend you for publicizing the thought process.  However, I’ve explained (or tried to explain) the differences between Visual Studio 2005 and .Net 2.0 too many times.  .Net 3.0 (which includes 2.0) definitely complicates things further.  I’d prefer "2.x with WinFX" or just "2.x".

    Your point about the easier deployment is a good one, but, in this case, the perception will take a back seat to reality.  "Oh no, we are not going to .Net 3.0, we just made the leap to 2.0 a few months ago.  We can’t afford constant upgrades and conversions, we need to develop software."  I’ve personally spent the past few weeks fine tuning a 1.1 to 2.0 conversion process.  It’s third party controls that turn the 1-2 day process into 2-3 weeks, but it’s still part of the process.  

  17. bioLogic says:

    As far as I know, current .Net frameworks depend on win32 on win2k & XP. So if Vista has .Net 3.0 instead of win32, will it be supporting .Net 1.1?

  18. Al Mahani says:

    I would have to agree with the aforementioned posts. WinFix is a service that is being added to the framework. It is almost like calling visual studio 2005 to visual studio 2006 because a major plugin was added.  How about .net framework 2.0 sp1. This would follow a consistent pattern with os upgrades. Another example is windows xp.  Features are added in the form of service packs. You do not rename windows xp to windows xp 2. You ship windows xp sp1 and so forth.  I really hope you guys rethink this.

  19. >So if Vista has .Net 3.0 instead of win32, will it be

    >supporting .Net 1.1?

    You are programming against the .NET 1.1 framework and not the underlying Win32 api’s by the way .NET 3.0 is nothing more than a set of extensions built with .NET 2.0 but these taken together become .NET 3.0

  20. Balamurali Balaji says:

    For me, anything (a service or add-in or component) that is newly plugged-in to .Net 2.0 or Visual Studio 2005 is new.

    With respect to .NET 2.0 + WinFx seems to be a new way of developing applications, that too with greater hardware inclination.

    Naming it as .NET 3.0 is reasonably correct, even though there are no changes in the CLR/FCL.

    Let us accept .NET 3.0 with what it has now(.NET 2.0+WinFX) on as-is-where-is basis and wait for .NET 4.0 for a down-to-earth change!

  21. Welcome .NET 3.0!

    In simple words .NET 3.0 means more managed code. Formally .NET 3.0 known as…

  22. Mike says:

    Most important of all (and related to MiniMSFT’s comments on MSFT in general) is that Soma posted this on his weblog, got a bucketload of negative feedback, and basically did nothing with that. So far for ‘developers developers developers’ because the people that come up with this just don’t care about developers.

    WinFX becoming .NET? No big problem to me. But what you said here bugs me (about the decision on 2.1 vs 3.0):

    "The main reason I changed my mind on this … I didn’t want to end up with version numbers such as 2.5, 2.75, 2.87.5."

    Sorry, I call BS here. So far you have released 1.0, 1.1 and 2.0, so don’t be saying that all of a sudden you would release so many updates that would make you run out of numbers. 2.1 would do very well for now, at most there would be a 2.2 and 2.3.

    Most developers are not dumb, and most of us have experience with management layers that speak that other language (corporate speak, also known as weasel words). I suspect that 3.0 is just to impress (look ma, I made another one), but as you might have noticed, developers are not impressed. You can’t fool someone for whom versioning is part of their job into believing some weird versioning scheme with weak arguments about running out of numbers. Not on a MSDN blog.

    Here’s a list:

    Windows 3.11 > Windows 95 > 98 > ME

    Windows NT4 > 2000

    Windows XP > Vista

    Office 95 > 2000 > 2002 > XP > 12

    VS.NET > VS 2005

    .NET 1.0 > .NET 1.1 > .NET 2.0

    Look at the list, the .NET Framework is the only thing that has a consistant versioning. But you let it slip into the hands of the marketing fools, and now you are ‘happy’ with the reactions of developers…

    I’m looking forward to your reactions!

  23. Tony says:

    Normally i do not blog/reply.  

    I have to say all kudo’s to Mike for highlighting the BS 🙂

    I strongly beileve that we are responsible for keeping it straight and we let it slide – thene we cannot complain…

    However, this is a major problem trying to explain to "premier" clients… prime developers are the frontline and the reason they are prime – is they will "call it as they see it" if MS does not care – well its their loss – cos i tell my clients exactly how it is – and and the version # changes stinks like the java versioning (only the versioning of Java)

    … so of those who wanna suck it up – go right ahead – cos there are "prime" developers who will stand up come hell or high-water!

    Brad – dont sell your sould bud -it aint worth it – Keep it up Mike!


  24. Khadir Syed says:

    Can u please mail me what are the advantages of .net 3.0 over .net 2.0 and now can we call .net 3.0 as winfx

  25. .Net Versions, 2 Years From Now

Comments are closed.

Skip to main content