Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
.NET Framework Versions: Marketing vs. Reality
Posted 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
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).
RelatedVendorContent
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Agile Maturity Model Applied to Building and Releasing Software
18 agile and lean practices for effective software development governance
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
.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
-
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 -
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. -
Hi Scott, I'm awfully sorry for linking to your image inline. You're right about the image policy. I've removed the link.
-
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". -
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? -
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 ...
-
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. -
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! -
> 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. -
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.
10 comments
Watch Thread Reply