Referencing .NET 2.0 but end result uses .NET 3.5

[Israel]

I'm using DevStudio 2005 and I have a project that references
System.dll ver 2.0.50727 and I accidentally compiled code that used an
overload that only exists in version 3.5 because my intellisense
showed it.
I tried to compile it on another machine that never had the .NET 3.5
install and it wouldn't compile and the intellisense had that version
of the overload yet both references looked identical; looking at ver
2.0 of System.dll
The method in question was WaitHandle.WaitOne.

..NET 2.0
WaitOne()
WaitOne(Int32, Boolean)
WaitOne(TimeSpan, Boolean)

..NET 3.5
WaitOne()
WaitOne(Int32)
WaitOne(TimeSpan)
WaitOne(Int32, Boolean)
WaitOne(TimeSpan, Boolean)

I used the one that just takes an int.

How can I guarantee that I only use .NET v2.0 dlls if the references
are obviously lying??? I don't want to accidentally compile it
against 3.5 and then put it on a machine that doesn't support that
version and wonder why it won't run.

 

[RayLopez99]

How can I guarantee that I only use .NET v2.0 dlls if the references
are obviously lying???  I don't want to accidentally compile it
against 3.5 and then put it on a machine that doesn't support that
version and wonder why it won't run.

Reinstall? You are screwed, sorry to say. This happens when you have
several versions of VS --a real pain.

RL

 

[Peter Duniho]

I'm using DevStudio 2005 and I have a project that references
System.dll ver 2.0.50727 and I accidentally compiled code that used an
overload that only exists in version 3.5 because my intellisense
showed it.
I tried to compile it on another machine that never had the .NET 3.5
install and it wouldn't compile and the intellisense had that version
of the overload yet both references looked identical; looking at ver
2.0 of System.dll
The method in question was WaitHandle.WaitOne.
[...]
How can I guarantee that I only use .NET v2.0 dlls if the references
are obviously lying??? I don't want to accidentally compile it
against 3.5 and then put it on a machine that doesn't support that
version and wonder why it won't run.

You should be able to set the "exact version" property for the reference
to force a specific version to be used. That will unnecessarily
restrict your application to older versions of the assemblies, but I
think in VS2005 that's as close as you can get.

A better approach would be to use VS2008 or later, which allows you to
set the project to target a specific version of .NET, without actually
forcing a dependency on a specific DLL version.

Of course, another option if you must use VS2005 is simply to make sure
you are doing your development work in the same environment that you're
targeting. If you can't dedicate a separate machine for that purpose,
you could use a VM. Windows 7 includes XP Virtual Mode (well, you have
to download it, but it's free), which you could use for that.

Pete

 

[Israel]

You should be able to set the "exact version" property for the reference
to force a specific version to be used.  That will unnecessarily
restrict your application to older versions of the assemblies, but I
think in VS2005 that's as close as you can get.

Actually that doesn't seem to work. I set "Specific Version" on the
System reference to True and rebuilt it and it was perfectly happy to
use the .NET 3.5 version even though I specified the 2.0 version and
Specific Version = True

 

[Israel]

Actually that doesn't seem to work.  I set "Specific Version" on the
System reference to True and rebuilt it and it was perfectly happy to
use the .NET 3.5 version even though I specified the 2.0 version and
Specific Version = True

The System.dll that ended up in the debug folder was the same either
way; version 2.0.50727.3053 but it's like that version actually has
3.5 APIs in it on my machine but not on other people's machines???
On my machine I can only find 2 System.dlls - one in C:\WINDOWS
\Microsoft.NET\v1.1.4322 and one in v2.0.50727. If I look at
installed programs I see:
..NET FW 1.1
..NET FW 2.0 SP 2
..NET FW 3.0 SP 3
..NET FW 3.5 SP 1

 

[Israel]

I guess it turns out that the System.dll under the "2.0" folder was
replaced for 3.5
so the original version was 2.0.50727.1433 but if you have .NET
installed then it's 2.0.50727.3053

Therefore once you install 3.5 there's no way to ever go back to 2.0
even though it seems like you should. The problem I have with this
type of versioning is that our install only checks that a machine has
2.0 installed because that's what we thought we needed. Now it really
needs to check that 3.5 is installed but hopefully they don't continue
this pattern into future releases.