Wow, it is great to see the level of passion around the .NET Framework! I wanted to add some additional comments to the discussion to continue to clarify some things.
One thing that is clear to me in reading through the comments is that many have been thinking of WinFX as a separate thing from the .NET Framework. That’s actually not at all how we think of it. From my perspective the Framework has the following functionality:
Base level functionality required to build and execute managed code. This includes things like the CLR and BCL to execute the managed code environment. It also includes some minimal subset of compiler technology for generation of managed code at runtime (e.g. C# and VB compiler).
Host level functionality that allows you to write application server style functionality. Asp.Net is a great example of this kind of functionality. SQL Server is another example.
A set of rich libraries for many types of problem spaces:
· User interface code
· Web services
· Web server
In each new version of the .NET Framework, we continue to work on the depth and breadth of our coverage. For example, in .NET FX 2.0 we added generics and serial port to the Engine Core, SQL hosting for Platform Technology, and many new features in the Functional Libraries like ClickOnce for client applications.
The rate at which we change pieces of the stack will vary. For example, it took us a long time to create a truly built in generics technology that wasn’t just templates. And once generics were cooked at the core, we had to then plumb out the rest of the system on top. There are similar kinds of features underway for the next major revision of the CLR. We wouldn’t want to hold all new innovation for that.
There are a number of significant improvements in the release we are now calling .NET Framework 3.0:
Additional hosting support with Windows Communication Foundation (WCF, “Indigo”).
· New user interface code model with vector graphic support
· Advanced web services functionality
· Built in work flow for advanced business applications
· Advanced security against phishing
All of these new improvements live in the “System.” namespace. They execute using the managed code engine core. You’ll recognize the technology names as Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), Work Flow Foundation (WF), and Windows CardSpace (WCS). Even though we have added these new technologies to the .NET Framework, your existing applications will continue to execute and you can safely continue your investments using the technologies which shipped with the .NET Framework 2.0 (in fact we will continue to make improvements across the stack!).
How Do I Install the Right Framework on a Machine?
We’ve tried to make authoring your application against the .NET Framework very simple. For each version of the .NET Framework, there is a bootstrapper installation program that will set up your machine with the right set of components. So for example if you are writing a WPF client application and therefore want to use .NET Framework 3.0, you simply use the bootstrapper for that version to do the installation. It will automatically detect if you already have .NET FX 2.0 on the machine and skip that piece if so.
Several of the other questions that have been raised are around trying to get a handle on which version of .NET FX will contain which feature. This is actually pretty easy:
1. .NET Framework 3.0 makes improvements to the feature areas I mentioned through WPF, WCF, WF, and WCS.
2. Our “Orcas” release (likely to be called version 3.5) adds new features like LINQ which in turn requires new versions of the C# and VB compilers. But even with new compilers you don’t have to try and pick through a bunch of files to figure out how to make LINQ work. If you need the feature, simply deploy the “Orcas” bootstrapper and call it a day.
So the way to figure out what you need is pretty simple: what feature did you want to use? What .NET Framework version did it ship in? Grab that bootstrapper and go.
How Are the Version Numbers Picked Anyway?
There was a lot of debate around this. First of all, we should separate version numbers into two things: (1) version numbers used for binding when executing an application, and (2) the public name for the redist. The former is used by our compilers and loader to ensure you get the right set of code at runtime. None of the changes Soma announced have any impact on this.
The latter is the “branded name” for the redist we are shipping. The name is picked by marketing and they use the same kind of logic that goes into picking major version numbers for applications, operating systems, etc. In the specific example of .NET Framework 3.0, there is a lot of new compelling improvements to the technology that warrant a major version number for the redist. Again, this has no impact on how your code is compiled, installed, loaded at runtime, or even serviced once deployed.
From my perspective Soma’s blog is very accurate: this really is just a rename of the redist. You will see very few actual changes compared to the last CTP of the 3.0 content you may already have installed. These changes will simply move the install directory to be more consistent with .NET FX 2.0 and update a few registry keys to match the name change (we are working on a CTP with these changes as we speak). Your installation experience is meant to be very simple, and the decision process for picking a framework version is simple as well (pick the version of the Framework that contains the features you want).
Finally, I plan to do a couple of extra follow up posts on a couple of topics that I’ve seen a lot of passion on: understanding red/green bits in this model, more precision on what features are in each version, and some additional prescriptive guidance on things like frameworks version detection. Let me know if you have other topics here that you’d like to see more details on.
Thanks for all the feedback and keep those comments coming!