.NET Framework Versions: Marketing vs. Reality

by Hartmut Wilms on Apr 08, 2008 |

Since .NET Framework 3.0 Microsoft's versioning strategy confuses the community. Scott Hanselman explains the how and why of the drift between marketing and reality.

The whole versioning issue resurfaced in the question Scott Hanselman answers in his article about "How to set an IIS Application or AppPool to use ASP.NET 3.5 rather than 2.0". Developers wonder how to configure IIS in order to make use of the new LINQ features or WCF's REST support in their applications.

The answer to this question is quite simple: configure your application to use .NET Framework 3.5 within your web.config as "the really important stuff is the and the newly added assemblies in the assemblies section", not in IIS. Your AppPool must still use the 2.0 version of the CLR, i.e. .NET Framework 2.0.

The confusion concerning versioning is most likely rooted in the assumption "that each major version of the Framework meant a new CLR". In fact the CLR is still based on the 2.0 version, which means that "Framework version != CLR Version":

.NET Framework 1.x = CLR 1.x

.NET Framework 2.0 = CLR 2.0

.NET Framework 3.0 = CLR 2.0

.NET Framework 3.5 = CLR 2.0 + (C# 3.0 | VB9)

Thus the .NET Framework version has become a kind of "marketing term", which tells nothing about the CLR or compiler version.

The .NET Framework 3.0 added "three major new libraries: WCF (Windows Communication Foundation née Indigo), WPF (Windows Presentation Foundation née Avalon) and Windows Workflow or WF", only:

Bottom line: Installing .NET 3.0 doesn't fundamentally change your system in any way you should fear. Your 2.0 apps still run on a system with 3.0 installed. They are 2.0 apps using the 2.0 compilers and 2.0 CLR.

In .NET Framework 3.5 "new language compilers for C# and VB", which are necessary for all the new language features that make up LINQ, were introduced. In addition some new assemblies have been added, such as "the REST support added to Windows Communication Foundation" and the inclusion of ASP.NET AJAX, which was formerly available as a separate download.

Marketing and reality might join again , if the .NET Framework 4.0 will incorporate the Dynamic Language Runtime (DLR).

Related Editorial

Cluster-Wide Caching & Scaling for the Cloud - A Look Inside Resin 4.0

Why NoSQL - Three Trends Disrupting the Database Status Quo

Getting Ahead in the Cloud: The Need for Better Identity and Access Controls

Application Performance Management Buyer's Guide

Enterprise-class API Patterns for Cloud & Mobile

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

.NET Framework by Bela Babik Posted

Re: .NET Framework by Hartmut Wilms Posted

Re: .NET Framework by Bela Babik Posted

Re: .NET Framework by Hartmut Wilms Posted

Please don't leech images... by Scott Hanselman Posted

Re: Please don't leech images... by Hartmut Wilms Posted

Thinking seems a bit narrow to me by Rod Hughes Posted

Re: Thinking seems a bit narrow to me by Hartmut Wilms Posted

Re: Thinking seems a bit narrow to me by Rod Hughes Posted

Re: Thinking seems a bit narrow to me by Vijay Santhanam Posted

.NET Framework by Bela Babik

Is this a joke?

".NET Framework" is a framework, why on earth would it be versioned by it's compiler or runtime version?

"Marketing and reality might join again , if the .NET Framework 4.0 will incorporate the Dynamic Language Runtime (DLR)."

???

"The Dynamic Language Runtime (DLR) is a layer on top of the .NET Framework 3.5 aiming at help you to build dynamic languages in .NET."

Source: www.dotnetguru.org/us/dlrus/DLR2.htm

Please don't leech images... by Scott Hanselman

That image is hosted at my site, and you're linking to it inline, and additionally it's not hotlinks. That's kind of a blogging etiquette no-no. You you always host images locally and link them back to the site you found it at.

I'd like to ask that InfoQ not blog "abstracts" from my blog anymore.

Re: Please don't leech images... by Hartmut Wilms

Hi Scott, I'm awfully sorry for linking to your image inline. You're right about the image policy. I've removed the link.

Re: .NET Framework by Hartmut Wilms

Bela, I can't follow your arguments. First the .NET Framework is certainly more than an "ordinary" framework, because it might also include tools and compilers. Thus the distribution package consists of a framework in the sense of new assemblies featuring additional functionality and (optionally) changes to the CLR or language compilers.
As for the DLR you might have a look at Jim Hugunin's article I'm linking to: "The new Dynamic Language Runtime (DLR) adds a small set of key features to the CLR to make it dramatically better. It adds to the platform a set of services designed explicitly for the needs of dynamic languages". Another good explanation of the DLR is found in a comment by Benji Smith on Joel Spolski's question about the DLR ( discuss.joelonsoftware.com/default.asp?joel.3.4...): "So the DLR includes a new opcode called InvokeDynamic, which supports method invocations on unknown on non-existent methods.

Additionally, dynamic languages often allow classes to be dynamically redefined by program logic (which is disallowed by both the CLR and the JVM)."
These are definitively changes to the language runtime, which will be incorporated into the CLR (on top) within a new release of the .NET "Framework".

Thinking seems a bit narrow to me by Rod Hughes

Since the applications developed upon the .NET Framework are tied to a specific version of the Framework (CLR version plus guaranteed available libraries) I find it hard to argue that the Framework version is purely a marketing abstraction.

I personally find the 1.0, 2.0 and 3.0 versions of the Framework to be appropriate major releases. 2.0 added the 2.0 CLR, ASP.NET 2.0; and 3.0 added powerful additions the technology stack (WF, WCF, WPF).

Whoever said the Framework version is supposed to be tied directly to the CLR version?

Re: Thinking seems a bit narrow to me by Hartmut Wilms

Rod, no one says that the Framework version is supposed to be tied directly to the CLR version. I was writing about an "assumption". What are the criteria for a major release? To me (and maybe to others) a change to the compiler or CLR is more of a major impact (from a technical/platform perspective) than adding features to the technology stack. These are definitively powerful additions, but they are additions, which have rightly been "sold" as an enterprise development stack. This is by no means bad, it is just another perspective on the Framework evolution. The really important point is that the community obviously seems to be confused about the Framework versioning. Scott Hanselman's article helps to understand the reasons why ...

Re: Thinking seems a bit narrow to me by Rod Hughes

Yes, I agree that there is confusion among developers. I often find developers become confused about things being done from a non-developer perspective (UI design decisions for example). It may be this is no different. The .NET Framework version number is exposed not only to developers, but also PC users and administrators. Developers always prefer things to follow some predictable and consistent pattern. Unfortunately, this does not always "reach" non-developers.

I worked as a developer in a marketing organization for 5 years. I took me personally 2 years to fully grasp that a developer point-of-view was not always the most effective point-of-view.

So I guess what I am saying is the the criteria for a major release is not as black and white as what makes sense to developers.

Re: Thinking seems a bit narrow to me by Vijay Santhanam

while superficially confusing, the fact the clr hasn't changed since v2 helped us sell the upgrade to management - they are overly cautious about tech upgrades though (without good cause).

and as a dev on the project, i couldn't care less about a new runtime, I just want at the new compiler + framework.

So, while the confusing versions befuddle new comers, it's saved me hundreds of hours in reality - thanks again MS!

Re: .NET Framework by Bela Babik

> First the .NET Framework is certainly more than an "ordinary" framework, because it might also include tools and compilers.

A framework can not include a compiler?

I still don't understand why is it important for you that which compiler is included in a framework.

> "So the DLR includes a new opcode called InvokeDynamic"

It may or may not will happen. As I can see, the JVM guys are sitting on the topic since 2006, and JRuby is working really well without it.

DLR is working on CLR 2.0 fine. Maybe it is not lightning fast, but that may not will be a priority.

Re: .NET Framework by Hartmut Wilms

In my opinion is .NET is a platform, which includes a framework, compilers, tools, and languages. Java is also a platform in the same sense.

I agree with Vijay that not changing the CLR has many benefits. However I would like MS to be more concise about what has changed and what the consequences are. Scott's article is a very concise explanation of the evolution of the platform/framework ...

Again, not changing the CLR and at the same time supporting dynamic languages has benefits. But in order to fully support all features of dynamic languages, the language runtime has to be changed.