.NET Framework versions

  • Thread starter Thread starter Peter Oliphant
  • Start date Start date
P

Peter Oliphant

If I tell the compiler to target .NET Framework 3.0 (one of the References
options in VC++ 2008 Express), does it still work if they only have a higher
version (say 3.5) of .NET Framework installed? Or does it look for and only
work with the specific version? The various various versions (e.g., 2.0
,3.0, 3.5) seem to install independently (i.e., I believe they are
co-resident, one doesn't seem to replace the other), so this is why I ask.
And of course I'm asking for future versions as well, such as 4.0, 5.0,
etc...

[==Peter==]
 
Peter Oliphant said:
If I tell the compiler to target .NET Framework 3.0 (one of the References
options in VC++ 2008 Express), does it still work if they only have a higher
version (say 3.5) of .NET Framework installed? Or does it look for and only
work with the specific version?

If you target a lower version of the framework in 2008, it will run on all
higher versions because they are cumulative from 2.0 to 3.5. That is, 3.5
contains 3.0 which in turn contains 2.0. This may not be the case with 4.0 or
whatever comes out after 3.5, since the CLR version might change. .Net 2.0,
3.0 and 3.5 are really just a cumulative set of assemblies on the core 2.0
CLR.
 
This may not be the case with 4.0 or
whatever comes out after 3.5, since the CLR version might change.

If this happened, would this mean everything written before 4.0 would stop
working for those end-users who only get into the game post 4.0? That seems
kind of drastic, and prone to legal action...(hehe)...

[==Peter==]
 
Peter Oliphant said:
This may not be the case with 4.0 or
whatever comes out after 3.5, since the CLR version might change.

If this happened, would this mean everything written before 4.0 would stop
working for those end-users who only get into the game post 4.0? That seems
kind of drastic, and prone to legal action...(hehe)...

[==Peter==]

codekaizen said:
If you target a lower version of the framework in 2008, it will run on all
higher versions because they are cumulative from 2.0 to 3.5. That is, 3.5
contains 3.0 which in turn contains 2.0. This may not be the case with 4.0
or
whatever comes out after 3.5, since the CLR version might change. .Net
2.0,
3.0 and 3.5 are really just a cumulative set of assemblies on the core 2.0
CLR.
 
No, sorry for the confusion. My point was that the versions of .Net which VS
2008 targets - 2.0, 3.0 and 3.5 - are really just assemblies on the 2.0 CLR.
As such, you can think of 2.0, 3.0 and 3.5 as cumulative releases which just
add functionality to the 2.0 CLR. Any future version of .Net will likely run
on a different version of the CLR. I didn't mean to imply that 2.0 CLR
assemblies won't run on a future version of the CLR.

In VS 2008, "targeting" doesn't mean it produces a different binary, it just
means that it means certain assemblies need to be present: the 2.0 Framework
for 2.0, the Framework _and_ the WPF/WCF/WF assemblies for 3.0, and the
Framework, WPF/WCF/WF assemblies _and_ the LINQ assemblies and a few other
things for 3.5.

Peter Oliphant said:
This may not be the case with 4.0 or
whatever comes out after 3.5, since the CLR version might change.

If this happened, would this mean everything written before 4.0 would stop
working for those end-users who only get into the game post 4.0? That seems
kind of drastic, and prone to legal action...(hehe)...

[==Peter==]

codekaizen said:
If you target a lower version of the framework in 2008, it will run on all
higher versions because they are cumulative from 2.0 to 3.5. That is, 3.5
contains 3.0 which in turn contains 2.0. This may not be the case with 4.0
or
whatever comes out after 3.5, since the CLR version might change. .Net
2.0,
3.0 and 3.5 are really just a cumulative set of assemblies on the core 2.0
CLR.
 
Back
Top