VMware Infrastructure 3 Book Excerpt and Author Interview
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
Tracking change and innovation in the enterprise software development community
Posted by Hartmut Wilms on Apr 08, 2008 04:26 PM
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).
The Agile Business Analyst: Skills and Techniques needed for Agile
The End of Middleware: Freedom from IT Stacks as we know it
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
Gamma's Jazz platform's first implementation: Rational Team Concert (Trial Download)
Alternatives in the .NET Space: Open Source, Frameworks and Languages @ QCon SF Nov 19-21
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: http://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 ( http://discuss.joelonsoftware.com/default.asp?joel.3.489066.5): "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.
VMware Infrastructure 3: Advanced Technical Design Guide and Advanced Operations Guide provides a wealth of practical insights into setting up virtualization in todays corporate environments.
Can a system that is so large it cannot be comprehended be "designed" in a conventional sense? The foundations of computing are about to change. In this talk, Richard P. Gabriel explores why and how.
Ruby 1.9's Fibers and non-blocking I/O are getting more attention - we talked to Mohammad A. Ali of the NeverBlock project and Tony Arcieri of the Revactor project.
Tim Mackinnon talks about the aspirations behind the Agile principles and practices, the desire to become efficient, to write quality code which does not end up being thrown away.
Brian Goetz discusses the difficulties of creating multithreaded programs correctly, incorrect synchronization, race conditions, deadlock, STM, concurrency, alternatives to threads, Erlang, Scala.
Often the hardest part of changing technologies is language syntax differences. This new article provides Java developers with a transition guide to Actionscript which forms the foundation of Flex.
Neal Ford talks about having multiple languages running on one of the two major platforms: Java and .NET. He also presents the advantages offered by Ruby compared to static languages like Java or C#.
David Anderson talks about the history of Agile, the current status of it and his vision for the future. The role of Agile consists in finding ways to implement its principles.
10 comments
Reply