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
Anonymous
June 10, 2006
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.Anonymous
June 10, 2006
The comment has been removedAnonymous
June 10, 2006
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.Anonymous
June 10, 2006
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.Anonymous
June 10, 2006
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".Anonymous
June 10, 2006
I still don't get it.
Why needed WinFX a name-change in the first place!? Don't start with "there was much confusion"!Anonymous
June 10, 2006
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?Anonymous
June 11, 2006
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.Anonymous
June 11, 2006
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?Anonymous
June 11, 2006
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?
JonAnonymous
June 11, 2006
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.Anonymous
June 12, 2006
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.Anonymous
June 12, 2006
The comment has been removedAnonymous
June 12, 2006
PingBack from http://blog.markwillems.nl/DetailsView.aspx?PostingID=f838a915-e5ed-49e8-ba80-6a267441ab3fAnonymous
June 12, 2006
This is all over the Microsoft blogs: so if you're following them you've no doubt already seen this (more...Anonymous
June 12, 2006
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.Anonymous
June 12, 2006
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.Anonymous
June 14, 2006
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?Anonymous
June 15, 2006
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.Anonymous
June 15, 2006
>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.0Anonymous
June 26, 2006
The comment has been removedAnonymous
June 30, 2006
Welcome .NET 3.0!
In simple words .NET 3.0 means more managed code. Formally .NET 3.0 known as...Anonymous
August 15, 2006
The comment has been removedAnonymous
August 26, 2006
The comment has been removedAnonymous
September 05, 2006
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 winfxAnonymous
January 13, 2007
.Net Versions, 2 Years From NowAnonymous
March 22, 2008
PingBack from http://carsmaxblog.info/somasegars-weblog-net-framework-30/