re: More on .NET Framework 3.0 Naming...

Philip — Wed, 14 Jun 2006 03:38:27 GMT

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!

.NET 2.0 + WinFX is now .NET 3.0

Ardent Dev — Wed, 14 Jun 2006 03:53:55 GMT

.NET 2.0 + WinFX is now .NET 3.0

derek hatchard — Wed, 14 Jun 2006 08:35:59 GMT

Posted at Ardent Dev by Derek Hatchard (Go directly to post):
In case you've missed all the noise...

re: More on .NET Framework 3.0 Naming...

Fduch — Wed, 14 Jun 2006 11:25:14 GMT

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?

.NET Framework 3.0

Softwareentwicklung ist COOL! — Wed, 14 Jun 2006 13:58:47 GMT

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

re: More on .NET Framework 3.0 Naming...

ringi — Wed, 14 Jun 2006 14:01:03 GMT

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.

re: More on .NET Framework 3.0 Naming...

jasonz — Wed, 14 Jun 2006 16:44:55 GMT

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

re: More on .NET Framework 3.0 Naming...

Fduch — Wed, 14 Jun 2006 17:02:11 GMT

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 ?

re: More on .NET Framework 3.0 Naming...

Philip — Wed, 14 Jun 2006 19:51:34 GMT

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

re: More on .NET Framework 3.0 Naming...

jasonz — Wed, 14 Jun 2006 20:22:00 GMT

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.

re: More on .NET Framework 3.0 Naming...

Gary — Wed, 14 Jun 2006 22:46:06 GMT

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?

re: More on .NET Framework 3.0 Naming...

Fduch — Thu, 15 Jun 2006 01:54:06 GMT

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?

re: More on .NET Framework 3.0 Naming...

Norman Diamond — Thu, 15 Jun 2006 03:31:49 GMT

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

re: More on .NET Framework 3.0 Naming...

jasonz — Thu, 15 Jun 2006 07:25:52 GMT

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

re: More on .NET Framework 3.0 Naming...

davidacoder — Thu, 15 Jun 2006 14:23:19 GMT

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.

re: More on .NET Framework 3.0 Naming...

jasonz — Thu, 15 Jun 2006 18:28:32 GMT

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

re: More on .NET Framework 3.0 Naming...

davidacoder — Thu, 15 Jun 2006 19:14:33 GMT

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

re: More on .NET Framework 3.0 Naming...

jasonz — Thu, 15 Jun 2006 20:19:56 GMT

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.

re: More on .NET Framework 3.0 Naming...

Fduch — Thu, 15 Jun 2006 23:01:09 GMT

What can you say about Microsoft Phoenix and its shedule?

re: More on .NET Framework 3.0 Naming...

jasonz — Fri, 16 Jun 2006 07:41:26 GMT

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

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

Smorgasbord 5

Ian Nelson — Fri, 16 Jun 2006 17:18:39 GMT

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

re: More on .NET Framework 3.0 Naming...

PatriotB — Sat, 17 Jun 2006 07:25:41 GMT

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

re: More on .NET Framework 3.0 Naming...

PatriotB — Sat, 17 Jun 2006 07:28:20 GMT

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

Orcasリリース時の.NET Fxのバージョンは3.5らしい

OPC Diary — Sun, 18 Jun 2006 18:14:36 GMT

Jason Zander's WebLog : More on .NET Fra...

re: More on .NET Framework 3.0 Naming...

Nosheen — Mon, 19 Jun 2006 08:32:02 GMT

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

re: More on .NET Framework 3.0 Naming...

John McMillion — Mon, 19 Jun 2006 19:51:34 GMT

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

re: More on .NET Framework 3.0 Naming...

Jigar Mehta — Tue, 20 Jun 2006 21:08:20 GMT

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

re: More on .NET Framework 3.0 Naming...

davidacoder — Wed, 21 Jun 2006 12:42:13 GMT

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.

re: More on .NET Framework 3.0 Naming...

davidacoder — Wed, 21 Jun 2006 12:46:42 GMT

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

re: More on .NET Framework 3.0 Naming...

davidacoder — Wed, 21 Jun 2006 12:51:13 GMT

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

re: More on .NET Framework 3.0 Naming...

Fduch — Mon, 26 Jun 2006 02:21:04 GMT

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

re: More on .NET Framework 3.0 Naming...

davidacoder — Thu, 29 Jun 2006 10:30:01 GMT

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!

WinFX becomes .NET 3.0 - blessing or a curse?

Bring It On — Wed, 12 Jul 2006 12:22:24 GMT

Getting started with .NET Framework 3.0 - Attend the MSDN Belux event

B# .NET Blog — Sat, 12 Aug 2006 17:09:43 GMT

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

links for 2006-10-21

People Over Process — Sat, 21 Oct 2006 10:21:45 GMT

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

Mike Taulty's Blog : .NET Framework 3.0 and "3.5"

Mike Taulty's Blog : .NET Framework 3.0 and "3.5" — Fri, 27 Oct 2006 02:59:32 GMT

PingBack from http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2006/10/26/8938.aspx

More on .NET Framework 3.0 Naming… | NinethSense

More on .NET Framework 3.0 Naming… | NinethSense — Mon, 23 Mar 2009 13:46:08 GMT

PingBack from http://blog.ninethsense.com/more-on-net-framework-30-naming-2/

Jason Zander s WebLog More on NET Framework 3 0 Naming | Cast Iron Cookware

Jason Zander s WebLog More on NET Framework 3 0 Naming | Cast Iron Cookware — Wed, 27 May 2009 01:02:36 GMT

PingBack from http://castironbakeware.info/story.php?title=jason-zander-s-weblog-more-on-net-framework-3-0-naming

Jason Zander s WebLog More on NET Framework 3 0 Naming | Quick Diets

Jason Zander s WebLog More on NET Framework 3 0 Naming | Quick Diets — Tue, 09 Jun 2009 13:56:42 GMT

PingBack from http://quickdietsite.info/story.php?id=2629

Jason Zander s WebLog More on NET Framework 3 0 Naming | Hair Growth Products

Jason Zander s WebLog More on NET Framework 3 0 Naming | Hair Growth Products — Wed, 10 Jun 2009 05:38:28 GMT

PingBack from http://hairgrowthproducts.info/story.php?id=1656

Jason Zander s WebLog More on NET Framework 3 0 Naming | Insomnia Cure

Jason Zander s WebLog More on NET Framework 3 0 Naming | Insomnia Cure — Sat, 13 Jun 2009 09:40:20 GMT

PingBack from http://insomniacuresite.info/story.php?id=8775