More on .NET Framework 3.0 Naming...

More on .NET Framework 3.0 Naming...

  • Comments 41

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:

Engine Core

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).

Platform Technology

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.

Functional Libraries

A set of rich libraries for many types of problem spaces:

·         User interface code

·         XML

·         Database

·         Web services

·         Web server

·         Etc…

 

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:

Platform Technology

Additional hosting support with Windows Communication Foundation (WCF, “Indigo”).

Functional Libraries

·         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.

In Closing

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!

  • Pros:

    -I do like the simplicity of just deploy the version you need.

    -.net has a better brand identity than anything (winfx, etc)

    Cons:

    - Change in meaning - the "engine core" was what many thought of as the runtime... always synced with a version.  Now, when installing .net 4.0 or 5.2 we don't know if we're installing a new runtime.  This is important for all the applications running on the machine that didn't include manifest directives for what version to prefer - I guess it's important now.

    - Confusion on when to regression test old applications... when 3.0 is installed? when 3.5 is installed? (see previous points)

    Questions:

    - When 2.0 SP1 comes out, will we see "requires .net 3.0 with .net 2.0 SP1"?  Or will there be a 3.0 SP1 at the same time that also patches 2.0? (so we can say "3.0 sp1"... I like that much better - what happens after a few sps? "requires 3.0 with SP3 and 2.0 SP2 installed"  ouch!)

    - Removal: I have a clean system, If I install 3.0 and then uninstall it am I left with 2.0 on my system?  

    Comments:

     I'm not against collapsing it all into .net at all- I like the idea of simplicity, believe me!
     But it's the  russian doll model that seems a bit problematic to me - Installing new versions of the runtime can affect all .net applications on the machine (or .net COM servers).   Having some releases do this and some not will be.. confusing, and hard to explain to customers.  Service packs for required runtimes (2.0) is also a bit of a confusion point to me.  I'd love more clarity!

    Thanks!


  • Posted at Ardent Dev by Derek Hatchard (Go directly to post):  
      In case you've missed all the noise...
  • I'm concerned about 3 things:
    What will be the version of mscorlib.dll and other BCL dlls?
    How will this impact orcas shedule?
    Why changing "Engine Core" is a minor change?
  • Viele haben sich sicherlich schon gefragt, wie das alles weitergehen soll mit WinFx und "parallel" dem...
  • Does this means that LINQ will not work on Windows 2000 for the sole reason that WPF will not work on Windows 2000 and the version of the framework that includes LINQ will also include WPF?

    Most of our customers still have some machines that run Windows 2000 and will do so for years to come.  I don't want to be locked out of all new versions of .NET just because they force WPF on me that we are not planning to use.
  • Philip - I definately here you on the con of the version number not immediately telling you how the underlying engine core is being versioned.  I rate at which the core changes in a dramatic way that requires side by side will be slow, so I do think we can communicate this well in advance.  We will also be publishing a white paper that describes how to code for this as well in a easy way that will keep working going forward.

    wrt the SP question, here again we want things to be simple.  Windows Update will therefore allow you to get the SP's you need, and if you deploy them yourself in the enterprise you will be able to install one SP for your version which will take care of the machine (in your scenario you wanted 3.0 then you would install or pre-req the SP of 3.0 you needed and it will automatically service the 2.0 installation).

    On removal, we have detection logic for how things got on the machine and use the native installation ref counting of the host OS (not always deterministic I know).  So if someone deployed a 2.0 application which only caused 2.0 to be installed, then you installed 3.0 which added just the 3.0 components, and you uninstall your app, we would still want to leave 2.0 on the machine.  This is the kind of problem any complicated software stack faces.  You could ask me why we don't just create a new version of the core with a 3.0 version stamp to avoid this.  However this also causes new issues (separate set of files to version and service, which one does VS use, a new redist to distribute broadly, etc).

    Fduch -
    1.  the engine core (including mscorlib and the rest of the BCL) are still version 2.0.
    2.  there is no impact to the Orcas schedule.  it had always been our intent to have one logical framework, we simply change the name.
    3.  changing the engine core in any very serious way (like introducing generics) is disruptive enough to require a new side by side release.  those changes we want to spread out more to avoid compat churn.  So in the 3.0 and 3.5 release timeframe, we have restricted ourselves to just minor changes in this layer by choice.

    Ringi - Any time we ship a new version of the Framework we look at what the most popular systems are that require coverage.  To state the obvious, there is a very high test cost as the matrix gets bigger (# of OS x OS SKU x CPU-type).  V2.0 will shipped in October 2005 and has a 10 year servicing window, so it will always run on Win2k.  LINQ will be in version 3.5 (your point).  We have not finalized the list of OS's that release will target. If we did support Windows 2000, it would only be for components of the framework (e.g. we won't make WPF work there).

    Jason
  • jasonz - Thanks for answering.

    " we don't just create a new version of the core with a 3.0 version stamp to avoid this. " - this is good!

    But how does it compel with ".NET FX 3.0 will be installed into the %windir%\Microsoft.NET\Framework\V3.0. "?

    I'm just curious will .NET FX 2.0 from ".NET FX 3.0 install to that folder too, or it would be left in %windir%\Microsoft.NET\Framework\v2.0.50727 ?
  • Jason : Thansk much for your answers!   I'm very happy about the service pack answer.    
  • Fduch - We should separate the physical directory structure from the side by side architecture.  In this case I refer to side by side as a new CLR engine core of which you can have only one in process.  When you activate your application, we are going to use the GAC to find your library components.  Having the files in a new directory won't change that behavior and makes it easier for us to author the install/uninstall code.

    .NET FX 2.0 will stay in the V2.0.50727 directory forever.
  • Just so it's completely clear, if I install the 3.0 SDK and runtime on my developer machine (Windows XP), will I still be able to build assemblies only using 2.0 libraries and deploy them to Windows 2000 machines?

    If so, are there any necessary steps I need to take besides not referencing 3.0 components?
  • Random thught:
    Imagine Orcas ships. And I make my application using VB9.0 with use of its new features and LinQ.
    Will users with bare Vista ( with .Net FX 3.0 preinstalled) be able to run my app, or the'll have to upgrade their framework?
  • > V2.0 will shipped in October 2005 and has a 10 year servicing
    > window

    Compare it to Windows.  Windows Server 2000 was shipping on new computers in 2003.  Does it have a 10 year servicing life on those computers?  Or will buyers be persuaded to reevaluate every 4 years if they might be better off switching platforms?
  • Gary - You can definately do what you describe.  Just make sure you only /r .NET FX 2.0 assemblies and you can deploy everything to Win2k.

    Fduch - LINQ is a feature of Orcas (3.5).  LINQ needs both a compiler and some library support.  A Vista user (or any 3.0 user for that matter) would therefore need to install the 3.5 framework in order to get the new libraries.

    Norman - The servicing terms are 10 years after the RTM of the product.  Since Win2k shipped in 2000 it will run out of support in 2010.  Whidbey shipped in 2005 which means its servicing window goes until 2015.  As an OS goes out of service, we generally no longer produce patches for it.  These are general guidelines, and the community will have plenty of heads up before such a boundary was crossed.

    Jason
  • But at least right now with the LINQ preview there is NO need to deploy a new version of the framework to clients in order to run programs that use LINQ. Which is beautiful, and I just HOPE, HOPE, HOPE you keep it that way. Right now LINQ programs run on .Net 2.0, because one can xcopy deploy the additional libraries needed with apps. Please, keep that! The major barrier with .Net is deployment of the framework. The more you can innovate on top of existing .Net 2.0 deployments (as you have shown with LINQ), the better.
Page 1 of 3 (41 items) 123