.NET Framework versions

[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==]

 

[Guest]

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.

 

[Peter Oliphant]

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==]

 

[Guest]

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==]

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.

 

[Guest]

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.

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==]

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.