.NET Framework 3.5

For anyone in the know, is the 3.5 framework simply an extension of the 2.0 framework (similar to how 3.0 is)? I notice that in Orcas, even when you tell it to target 3.5, it's pulling in a lot of system classes that are part of the 2.0 framework, so it doesn't seem like it's a complete replacement (as 2.0 was for 1.1).

What I'm getting at here is, if you build an application that targets 3.5, it seems like it will require both version 2.0 and 3.5 of the framework to be installed on the target system.

I ignore the "marketing" names for the CLR.

In reality, it goes something like this:

CLR/BCL1.0 - .NET 1.0
CLR/BCL1.1 - .NET 1.1
CLR/BCL2.0 - .NET 2.0
CLR/BCL2.0 + WinFX classes - .NET3.0
CLR/BCL3.0 + WinFC classes - .NET3.5

HTH

Thanks. What I'm saying though is that it seems like it's really this:

.NET 3.5 = BCL 2.0 + WinFX (+ BCL 3.0?)

If you create a new WinForms project in Orcas and target the 3.5 Framework, every single reference (System.Core, System.Drawing, System.Windows.Forms, System.Xml) is for version 2.0. I was surprised to see that they even versioned System.Xml.Linq as 2.0.

Unless I'm seriously confused, it seems as though they've versioned the tools as 3.5, but have downversioned the few class libraries that's actually part of 3.5 to 2.0. Take a look in C:\Windows\Microsoft.NET\Framework\3.5.20404 and you'll see there's hardly anything even in there, and the few assemblies that are, like System.Net.dll, are still versioned as 2.0.

As my final little test, I wrote a simple WinForms "Hello, World" application in C# targetted it for version 3.5 and compiled it. I then copied it to my live development system that doesn't have Orcas or the 3.5 Framework installed. Guess what? It ran. Now that, I didn't expect.

So it seems like 3.5 is yet even more meaningless mucking about with the .NET Framework versioning.

It may still run under the same framework, but the compilers are very much not the same.  There are significant language changes in .Net 3.5.

well in that simple ap you must have only used 2.0 features.

I look at it as onion shell additions.

you can write a 3.5 ap, and not use any 3.5 features. and it will run fine on a system that only has 2.0 installed, if you don't use 3.5 or 3.0 features.

There will be a slight update to the 2.0 layer.

3.0 will see some updates primarily to the wcf and wf layers. believe even some minor updates to wpf.

3.5 will have the Linq componets.  it may also be the designation used to use those feature updates to 3.0. 

the key part is you can take a 2.0 ap compile it as a 3.5 ap. and it will still run on machines with only 2.0 installed.

as you start using the features. Move the UI to WPF, start using WCF and WF for parts of the ap, and using linq for data access features then those parts will need to be installed to run the ap.

Douglas

DouglasH wrote:

well in that simple ap you must have only used 2.0 features.

I look at it as onion shell additions.

you can write a 3.5 ap, and not use any 3.5 features. and it will run fine on a system that only has 2.0 installed, if you don't use 3.5 or 3.0 features.

That's right, the CLR is (generally) backwards compatible. Assemblies built for CLR 1.0 that don't target any deprecated features will still run perfectly fine (if not better) on CLR 3.0

W3bbo wrote:

That's right, the CLR is (generally) backwards compatible. Assemblies built for CLR 1.0 that don't target any deprecated features will still run perfectly fine (if not better) on CLR 3.0

But an assembly that targets 3.5 will not work on a system that only has 1.0 installed. However, it will work on a system that only has 2.0, if no 3.x features are used.

The point is that Microsoft has skewed the framework versioning based on the tools, and additional assemblies, not the actual core classes that make up the framework. As I pointed out, even the new stuff in the C:\Windows\Microsoft.NET\Framework\v3.5.20404 folder is versioned as 2.0.

So where does this end? 3.5 consists of new compilers, tools and additional assemblies, but it's in addition to -- not a replacement of -- the core assemblies in the 2.0 framework. So, down the road when .NET Framework 6.0 is released, is that going to mean that end users are going to need everything from 2.0, 3.0, 3.5, 4.x, 5.x and 6.0 installed on their systems? Good grief.

IMHO, they should have made it so that major version changes to the CLR where whole and complete. If something targets 3.x, then the only thing that an end user should need installed on their system is the 3.x framework. Period, end of story. The way things are, this just makes redistribution even more of a mess.

But if you follow that argument to it's logical conclusion, 3.0 would've just duplicated an enormous number of the files already included in 2.0, which doesn't achieve anything. There isn't anything to stop Microsoft releasing just a .NET 3.0 redistributable that happens to install 2.0 as well, so where is the real issue?

The whole problem with complaints about the .NET versioning stems from the fact that you simply can't expect every update to the base class libraries to also require an updated CLR and a whole bunch of new languages features in every concievable .NET language. There is inevitably going to be some sort of disparity between version numbers at some point.

AndyC wrote:

The whole problem with complaints about the .NET versioning stems from the fact that you simply can't expect every update to the base class libraries to also require an updated CLR...

Sure I can, if it's a major version change. Everything you're saying makes sense if it was a minor version change, say from version 2.0 to 2.5. But pretty much everywhere other than .NET, a major version change implies a completely new version of the product. Not incremental changes that also require previous versions.
 
What they're doing would be the equivalent of saying that if your application links against the v9.0 C runtime DLL, that you also need to distribute the v8.0, v7.1 and v6.0 runtimes with your application as well.

It is what it is, but I think Microsoft munged this all to hell, starting when they labeled WinFX as version 3.0. And I fundamentally disagree with your notion that "version disparity" as you call it is inevitable. It is either the result of poor management, the interjection of marketing where it should not be, or both.

A rose is a rose is a rose...

I doubt that version 3.5 goes much longer as a layered onion I believe the next version of .net after 3.5 will choose a new foundation.

there was a catch 22 as .net was and is coming out.

what did we go 5 to 7 years with no vs upgrade to 1 every 2 years in the past 6 years.

the Base classes are stableized in the framework for the most part there are still minor tweaks going on but the framework itself is stable.

building on top of that and giving it a version number is questionable I grant that. I personally preferred framework plus Winfx over Version 3.

But I can also see the version 3.0 nomoclature. there may not be changes to the bcl, but there are significant changes with runtimes and support.  WF and WPF in particuliar make significant changes to runtime support.

so the BCL for Version 3 is Still Version 2.x the BCL for version 3.5 is still 2.x.  extentions beyond the BCL make the change the entire framework.

I see a change coming in version 3 of the BCL. and Silverlight offers some insite to that.

Currently the Desktop Libray loads everything including classes for visual tools (winforms) but we have a new sku and a new shell that can't run on the core Server OS skus. because they don't load the gui.

So I see a refactoring of the Desktop BCL coming soon. Not before longhorn server ships unfortantly but I see it coming.

So you will have a Framework Core that is command mode only. that provide the base functionality of language support. then you have the other cores that build upon that.

This will allow for headless Powershell implementation and scripting support.

Now looking at the features. C++ is not a self describeing language such as c# and the other managed languages. so the change makes since in that to maintain compatability between version upgrades.

typically changing the language dll for c++ would not adversly affect the programs running but on occasion it would break some when the new dll was added and features were removed or added to the langauge.  (aka dll hell) C# and the new languages and .net use a Manifest feature so if the feature is removed and can call on the older version of the dll forcably. 

the issue with 1.0 and 1.1 is that 1.1 replaced the library for the most part and caused some issues with certain feature fixed.  1.1 and 2.0 could run side by side and for the most part don't cause issues but not all 1.1 programs run good on 2.0 framework itself.

MS  has worked hard to stableize the framework and resolve compatability issues and stableize it as the current base to build upon.

Well enough rambleing.

douglas

Well, if we take it as it is .NET 3.5 is just a minor update from .NET 3.0. That's why it is no .NET 4.0. Most of the stuff is really only coming with the compilers.

I was wondering myself what really changed in the BCL for this version. But I was to lazy/busy to check that for now...

stevo_ wrote:

The argument about .NET 6 and having a back catalog of framework versions isn't very fair.

It's not like all of these are going to be installed for one, and the second is, what problems are associated with having all these versions? or are computer going to get slower and with less storage space in the future?

What's not fair about it? That looks exactly like the direction Microsoft is moving towards, with subsequent versions of the framework being "layered" over previous versions.

Sure, computers are going to be faster and have more storage. What does that have to do with requiring multiple versions of the framework be installed? In fact, it looks like Microsoft is trying to reduce the overall size of the framework doing it this way. My concern is both ideological (version numbers should actually mean something, and not just be a marketing vehicle) and practical (version skew is bad, and some "3.5" assemblies have been downversioned as 2.0).