More on .NET Framework 3.0 Naming…


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!


Comments (41)

  1. Philip says:

    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!

  2. Posted at Ardent Dev by Derek Hatchard (Go directly to post):  

      In case you’ve missed all the noise…

  3. Fduch says:

    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?

  4. Viele haben sich sicherlich schon gefragt, wie das alles weitergehen soll mit WinFx und "parallel" dem…

  5. Garry Trinder says:

    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.

  6. jasonz says:

    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

  7. Fduch says:

    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.NETFrameworkV3.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.NETFrameworkv2.0.50727 ?

  8. Philip says:

    Jason : Thansk much for your answers!   I’m very happy about the service pack answer.    

  9. jasonz says:

    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.

  10. Gary says:

    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?

  11. Fduch says:

    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?

  12. Norman Diamond says:

    > 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?

  13. jasonz says:

    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

  14. davidacoder says:

    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.

  15. jasonz says:

    David – we will definately continue to build on top of 2.0.  Xcopy deployment is somewhat orthoganal to that.  The early versions of LINQ are done this way because there is not setup ready yet for the Orcas release.  That will be be comming online later this year when we start doing full Orcas CTP’s.

    This one is probably worth a blog post of its own as I know there is a lot of passion around this (we have lots of long debates ourselves internally around this).

  16. davidacoder says:

    Well, the setup is the thing I don’t like 😉 So, are you saying that we will need to deploy .Net 3.5 on client machines in order to use LINQ? You guys are now at a yearly release schedule with the frameworks (.Net 2.0 in Oct 2005, .Net 3.0 in Oct 2006, .Net 3.5 in Oct 2007, according to Scott Guthrie). But it appears that the stuff that is coming in .Net 3.5 (LINQ) could actually run on .Net 2.0. Why on earth are you giving up this incredible deployment story?!?

    I wrote that already on Brad’s blog: All of you try to put this as a "this is only a marketing decision" in the public. But it is not. With this decision you will slow down adoption of .Net as the core platform for years. Because no sane person is going to bet on a platform that has major releases every year. The really crazy thing is that you seem to have a technical story that actually would allow you to NOT touch the .Net 2.0 stuff at all for at least two major additions of features over the next two years: WinFX and LINQ. Which is such an asset. And yet you just give it away by this stupid bundling… Also, I had a number of questions on Brad’s blog concerning the decrease in agility you get with this. What happens if WinFX 2.0 (well, next version of WPF, WFC etc) slips six months. Will that mean that LINQ will slip as well? Or will you have a .Net 3.5 with LINQ, and then six months later a .Net 3.6 with WINFX 2.0?!? Technically you got the depedency problem really well solved. And now you completly give all that away, because you package EVERYTHING into one huge package, and by definition onto one schedule. One wanders…

  17. jasonz says:

    David – there are a few concepts we should tease apart:

    1.  Ship velocity

    2.  Binding architecture

    3.  Deployment technology & experience

    Ship Velocity:

    Our general plan is to rev the core engine on a predictable schedule.  You don’t want major changes to the CLR every year.  But we do want the ability to bring new innovation to .NET on that scale.  It doesn’t mean everything in the stack churns on that schedule.  I do believe that as technology rapidly evolves in the industry, we need the kind of yearly pulse for things that Scott talks about.

    Binding Architecture:

    Nothing is changing here with 3.x.  You will be using the 2.0 CLR at the base.  When you build an app you will add a reference to the new assemblies you want to use, those assemblies will be bound from the GAC per your manifest information, etc.  

    Deployment Technology & Experience

    Installers are chained.  So your algorithm is to pick the version of the .NET FX that has the features you want to target and deploy the boostrapper for that version.  If you want LINQ, you pick 3.5.  that bootstrapper will only download the components you need to your machine.  So if you were on Vista for example, 3.0 is already on the machine and you will only get 3.5 added to the machine.  Doing this installation does NOT impact the 2.0 or 3.0 components that were already on the machine.

    Let me now walk back through your comments:

    "no sane person is going to bet on a platform that has major releases every year"

    >>>  You can choose which version you want to deploy and stick with that.  The changes in a new version are additive to the previous stack precisely to avoid churn.

    "The really crazy thing … NOT touch the .Net 2.0 stuff … for at least two major additions"

    >>>  I have outlined how I believe this is the case.  We are NOT touching the 2.0 bits.  3.0 and 3.5 ARE additive.

    "What happens if WinFX 2.0 (well, next version of WPF, WFC etc) slips six months. Will that mean that LINQ will slip as well?"

    >>> No.  We line up ship trains well in advance based on the development teams capacity and queued work.  LINQ is well underway for the Orcas (3.5) release.  In that release you are likely to see some fixes and improvements of all of the existing stack including WPF, WCF, etc.  As you pointed out above, we don’t want too many disconnected releases beause it causes confusion and too many permuntations to build/test/deploy.  So having a logical set of functionality that works well together on a regular rythym is a goal.

    "And now you completly give all that away, because you package EVERYTHING into one huge package, and by definition onto one schedule."

    >>> There is a hard balance to be had here.  We need to keep up the pace of innovation in the product which means new versions.  We also need to minimize permutations of that software to design something that trully scales to hundreds of millions of machines.  Developers are not happy when we release a lot of out of band stuff that impacts their existing apps.  We must be able to service the software easily in the case of a security problem.  We also want to make it easier for a developer to write their code:  it is far easier to simply say "I need .NET FX 3.5" and go.

    >>> All that said I do agree this approach does not scale forever.  I mentioned the analogy to cpan in one of my posts, where they have around 10,000 perl modules.  There is no way we would want to put that much stuff in one huge release.  So we are thinking about how we can continue to tune the system.

  18. Fduch says:

    What can you say about Microsoft Phoenix and its shedule?

  19. jasonz says:

    I’m not sure what the ship schedule is for Phoenix.  They did recently release an RDK:

    http://research.microsoft.com/phoenix/default.aspx

  20. Ian Nelson says:

    Gates to end daily MS role, to spend more time running his charitable foundation.  Say what you…

  21. PatriotB says:

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

    Originally it was.  Avalon and Indigo (and WinFS) were pillars of the original Longhorn: part of the Windows OS and developed by the Windows division (so we thought).  At that point, we were told that the main new Windows features were going to be built in managed code, on top of .NET.

    When did this all change?  With the big Longhorn reset?  The way it is now, with WinFX becoming .NET 3.0, it appears that WinFX is now no longer part of the Windows organization but is owned and developed by the MS Developer division.

    I can understand the confusion; you can trace it all the way back to the original Longhorn vision, and the lack of explanation of the changes in the Longhorn reset.

  22. PatriotB says:

    Oh, and thanks for clarifying what "Orcas" really is (.NET 3.5, VS 8.5).  I was always wondering if it was going to be a .1 release (implied by the quick ship cycle after Whidbey) or a full-version increase (implied by the numbering of C# 3.0 and VB 9.0).

    I suppose in terms of language improvements, the languages themselves do deserve a full version increase… we’ll all just have to get used to different versioning for different components (CLR, languages, etc.)

  23. OPC Diary says:

    Jason Zander’s WebLog : More on .NET Fra…

  24. Nosheen says:

    hi

    i want to know on which date .Net Frame work 3.0 is going to release officially? we are thinking to use its functionality but decision depends on its availibilty according to the schedule of our product release. So can u give me its exact date of release?

    thanks

    regards

  25. We are also considering a WPF Smart Client, but are wondering when the WinFX runtime will be at RTM.  Will it be before the OS rtm in Nov?  We are apprehensive about pushing a beta runtime to our customers through the SC.

    Thanks,

    John

  26. Jigar Mehta says:

    I want to ask some questions regarding .NET Framework 3.0

    1. Will it work on my development machine which is Windows XP ?

    2. Can I deploy my product having Windows 2000 ?

    3. Are/will we (be) having any control in Framework 3.0 like windows vista explorer, where thumbnail of an image can be resized using a slider control ? And will that run on Windows XP/2000 ? (because that might be using WPF)

    Regards,

    Jigar Mehta

  27. davidacoder says:

    Thanks for the good response! I have a few follow up questions:

    "We are NOT touching the 2.0 bits.  3.0 and 3.5 ARE additive."

    If that is true, great! So that means that WPF, WCF, WF and CardSpace 1.5 (don’t know what version number you will use, but the next version of those things) have to be purely additive. No touching of any of the DLLs that are deployed with the initial release. Is that realistic? Have those teams signed up to this? Again, here we have something that follows from the decision that is clearly NOT purely marketing and name related, right?

    Remember, if .Net 3.5 is additive for the CLR, BCL etc but NOT for the stuff formerly known as WinFX, than the good effect of the carefull updates of the CLR, BCL etc stuff is wasted. If I require .Net 3.5 for my app because of LINQ but risk to break other apps that use WPF by deploying .Net 3.5, than this solution is bad and keeping the two seperate would have been better.

  28. davidacoder says:

    "No.  We line up ship trains well in advance based on the development teams capacity and queued work."

    So you are telling me that in order to avoid the danger that a slip in WPF 1.5 might affect the ship date of the LINQ stuff, you are going to do superior planning and coordination?!? Oh my god… I had thought that the one thing learned by the Vista desaster (and I believe that the project planning part of Vista can only be called a disaster, right?) was that slips can only be avoided by decoupling stuff, NOT by attempting to just better plan stuff.

    This is about risk management, right? By coupling you increase the risk of not shipping LINQ on time. If three months before the planned ship date of .Net 3.5 you find out that the next version of WPF really needs four more months, than you will have to slip LINQ. So by this bundling decision you have increased the risk of slipping, I just don’t think there is any way to deny that, right? And I just don’t understand how that fits into the "we want to become more agile" theme…

  29. davidacoder says:

    "Installers are chained.  So your algorithm is to pick the version of the .NET FX that has the features you want to target and deploy the boostrapper for that version"

    Bootstrappers are a MAJOR deployment blocker. They are even worse than MSI setups. I just wish Microsoft would understand that at some point. One of your TOP priorities should be to avoid boot strappers. They can’t be deployed easily via GPO, they need admin rights, they can’t be used easily with ClickOnce (in a non-admin environment). They are the major, major blockers for ISVs. That was why initially I was so thrilled about the way the LINQ stuff seemed to work: At least with the current CTP, I don’t need to deploy ANYTHING to client machines. THAT is the way it should be. I don’t care how often I as a dev have to update my machine with new stuff, but EVERY effort should be made on your part to innovate on top of deployed .Net 2.0 platform for client apps, without needing a new bootstrapped deployment on the clients.

  30. Fduch says:

    I see you as reasonable person, Jason.

    How can you camment this disaster?

    http://blogs.msdn.com/winfs/archive/2006/06/23/644706.aspx#comments

  31. davidacoder says:

    Jason, any chance to get answers to my three previous comments here on the blog? Or at least on the "So WPF, WCF and WF 1.5 can’t exchange a single binary, have they agreed on that?" question? 🙂 Thanks!

  32. B# .NET Blog says:

    Fellow Belgian software guys, check out this great (free of charge) event that will take place in Brussels…

  33. Technorati Weblog: Blog Claiming with OpenId Technorati supports using OpenId to claim your blog(s) now. Nice list of plugins too. We outta get the MT one setup on RedMonk. (tags: openid plugins technorati identity2.0 claimid) Google sweeps earnings week..