What is the actual runtime version of .NET 3.5 framework?

  • Thread starter Thread starter Alex Chudnovsky
  • Start date Start date
A

Alex Chudnovsky

Hi all,

I am using release version of VS 2008 in projects targeting .NET 3.5,
however I just noticed that
System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion()
returns old "2.0.50727" - indicating that the code runs under .NET 2.0.

..NET 3.5 installed just fine - I resorted to creation of brand new
console project targeting .NET 3.5, it uses System.Linq, and compiles
and runs just fine, the test code I use is as follows:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine(".NET runtime version: {0}",
System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion());
Console.ReadLine();
}
}
}

There are no dependences on any old code in this example.

What's going on?!?! Can someone in the know confirm that this is
supposed to be the expected behavior (if so it is really really odd).

regards,

Alex
 
Alex Chudnovsky said:
I am using release version of VS 2008 in projects targeting .NET 3.5,
however I just noticed that
System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion()
returns old "2.0.50727" - indicating that the code runs under .NET 2.0.
Click to expand...

No, it indicates that it runs under *runtime* 2.0.50727. From the docs
for GetSystemVersion:

<quote>
Gets the version number of the common language runtime that is running
the current process.
</quote.

The CLR hasn't changed for .NET 3.5 - it's the same runtime version,
but with additional libraries, including language enhancements in the
compilers.
 
Jon said:
No, it indicates that it runs under *runtime* 2.0.50727. From the docs
for GetSystemVersion:

<quote>
Gets the version number of the common language runtime that is running
the current process.
</quote.

The CLR hasn't changed for .NET 3.5 - it's the same runtime version,
but with additional libraries, including language enhancements in the
compilers.
Click to expand...

CLR appears to be updated with new stuff from service pack, in any case
how would I know if my application runs under .NET 3.5 or .NET 2.0 SP1?
In any case build version (2.0.50727.*) does appear to miss from
information returned by GetSystemVersion().

Specifically what bothers me is this: I was made understood that .NET
3.5 features improvements to sockets code, so I recompiled my
application to see if anything changed, but looking at CLR version
number I am not clear whether it is running on old .NET 2.0, or new .NET
3.5, or maybe .NET 2.0 SP1 actually includes in itself these
improvements claimed to be present in .NET 3.5!?!

This is a very odd decision, maybe they should have called it .NET 2008,
at least there would have been no question that numeric value has
nothing to do with version number :-/

So, how do I know if my application runs on .NET 3.5 or not?

Say, if I choose VS target of .NET 3.5, does this guarantee that my
application run only if .NET 3.5 is actually installed?

regards,

Alex
 
Jon said:
No, it indicates that it runs under *runtime* 2.0.50727. From the docs
for GetSystemVersion:

<quote>
Gets the version number of the common language runtime that is running
the current process.
</quote.

The CLR hasn't changed for .NET 3.5 - it's the same runtime version,
but with additional libraries, including language enhancements in the
compilers.
Click to expand...

CLR appears to be updated with new stuff from service pack, in any case
how would I know if my application runs under .NET 3.5 or .NET 2.0 SP1?
In any case build version (2.0.50727.*) does appear to miss from
information returned by GetSystemVersion().

Specifically what bothers me is this: I was made understood that .NET
3.5 features improvements to sockets code, so I recompiled my
application to see if anything changed, but looking at CLR version
number I am not clear whether it is running on old .NET 2.0, or new .NET
3.5, or maybe .NET 2.0 SP1 actually includes in itself these
improvements claimed to be present in .NET 3.5!?!

This is a very odd decision, maybe they should have called it .NET 2008,
at least there would have been no question that numeric value has
nothing to do with version number :-/

So, how do I know if my application runs on .NET 3.5 or not?

Say, if I choose VS target of .NET 3.5, does this guarantee that my
application run only if .NET 3.5 is actually installed?

regards,

Alex
 
Alex Chudnovsky said:
CLR appears to be updated with new stuff from service pack, in any case
how would I know if my application runs under .NET 3.5 or .NET 2.0 SP1?
Click to expand...

Look at each of the assemblies it references, and see what their
versions are.
In any case build version (2.0.50727.*) does appear to miss from
information returned by GetSystemVersion().
Click to expand...

True. If you use System.Environment.Version you get the build number as
well.
Specifically what bothers me is this: I was made understood that .NET
3.5 features improvements to sockets code, so I recompiled my
application to see if anything changed, but looking at CLR version
number I am not clear whether it is running on old .NET 2.0, or new .NET
3.5, or maybe .NET 2.0 SP1 actually includes in itself these
improvements claimed to be present in .NET 3.5!?!
Click to expand...

Yes, it will. The assemblies making up .NET 3.5 are .NET 2.0SP1 and
extra assemblies for .NET 3.0(SP1) to do with WPF, WCF etc, and the
extra assemblies for the .NET 3.5-specific features such as LINQ.
This is a very odd decision, maybe they should have called it .NET 2008,
at least there would have been no question that numeric value has
nothing to do with version number :-/

So, how do I know if my application runs on .NET 3.5 or not?

Say, if I choose VS target of .NET 3.5, does this guarantee that my
application run only if .NET 3.5 is actually installed?
Click to expand...

No. If you don't actually reference any libraries which are only
present in .NET 3.5, it would run under .NET 2.0SP1 or .NET 3.0SP1 too.
If you use a type which is present in the service pack (e.g.
System.DateTimeOffset) then it would only run under .NET 2.0SP1 and
above, but otherwise it will run under .NET 2.0 (no service pack) too.
 
Jon Skeet [C# MVP] wrote:

Ok, you answered my question and I am grateful for that.
If you use a type which is present in the service pack (e.g.
System.DateTimeOffset) then it would only run under .NET 2.0SP1 and
above, but otherwise it will run under .NET 2.0 (no service pack) too.
Click to expand...

I just want to say that I think it would have been wiser of Microsoft to
increase reported version number rather than confuse people - it should
have never been .NET 3.0, maybe .NET 2.1 (reported as such - CLR or not,
there should be a single reportable function that gives version of
environment, this should include standard libraries), and maybe .NET 3.5
should have been reported as .NET 2.5, or whatever - just not add extra
functionality but report same version - I appreciate that technically
CLR is mostly the same, but it's not exactly the same, so they should
have changed version - if they confuse developers who developed for
their platform, what chance do users have?

Again thanks for your answer - this is just a mini-rant and offsets a
little public praise to .NET that I made today. I took my words back :/


regards,

Alex
 
Alex Chudnovsky said:
I just want to say that I think it would have been wiser of Microsoft to
increase reported version number rather than confuse people - it should
have never been .NET 3.0, maybe .NET 2.1 (reported as such - CLR or not,
there should be a single reportable function that gives version of
environment, this should include standard libraries), and maybe .NET 3.5
should have been reported as .NET 2.5, or whatever - just not add extra
functionality but report same version - I appreciate that technically
CLR is mostly the same, but it's not exactly the same, so they should
have changed version - if they confuse developers who developed for
their platform, what chance do users have?
Click to expand...

Well, I'd have preferred .NET 3.0 to be .NET 2.5, and .NET 3.5 as .NET
3.0 - I see no reason to couple the major version of .NET as a whole to
the runtime version.

However, I do agree that it's caused confusion to not bump the minor
version with the service pack.

I think there are reasons though. If you build an application with .NET
2.0SP1 installed, but don't reference any of the new types in the
service pack (and there aren't many of them) the app will still execute
on .NET 2.0 (no service pack). This is in stark contrast to the 1.1/2.0
difference.
 
Jon said:
Well, I'd have preferred .NET 3.0 to be .NET 2.5, and .NET 3.5 as .NET
3.0 - I see no reason to couple the major version of .NET as a whole to
the runtime version.
Click to expand...

That would be fine by me too. IMHO the whole point of version is to
indicate what standard libraries should be expected to be available as
standard. Maybe they had good reasons for compatibility to keep .NET 2.0
version number, odd though as surely the version number itself is not
exactly the reasons why stuff is not compatible.

What I wonder is whether .NET 2.0 targeted apps running on .NET 2.0 SP1
would benefit from socket related improvements allegedly present in .NET
3.5? We will probably never know for sure.

regards,

Alex
 
Alex Chudnovsky said:
That would be fine by me too. IMHO the whole point of version is to
indicate what standard libraries should be expected to be available as
standard.
Click to expand...

That would be appropriate as the version number for the framework, but
not for the runtime. Getting the runtime version number could be
important for other reasons (e.g. emitting the right IL etc)

It would be nice to have an easy way of finding out which .NET
framework versions are available on the machine though. It doesn't make
quite as much sense to ask what version of the framework a particular
process is executing - there's no difference between running under .NET
2.0SP1 and running under .NET 3.5 until you happen to load a type from
an assembly which is only in .NET 3.5.
Maybe they had good reasons for compatibility to keep .NET 2.0
version number, odd though as surely the version number itself is not
exactly the reasons why stuff is not compatible.

What I wonder is whether .NET 2.0 targeted apps running on .NET 2.0 SP1
would benefit from socket related improvements allegedly present in .NET
3.5? We will probably never know for sure.
Click to expand...

Yes, they will. Basically any enhancements to existing functionality
will be present in 2.0SP1 (or 3.0SP1 for WPF etc). New features will be
in 3.5.
 
Back
Top