VS 2005 guesses at DLL

[Brian Begy]

Has anyone else observed this:

1) Take a project that contains a reference to a dll.

2) Remove said dll from the original location.

3) Build project.

Instead of failing at compile time, as any sensible compiler should, we
see Visual Studio looking around and finding another dll of the same
name to replace the missing one. In every case, this causes a
versioning conflict at runtime instead of breaking on compile.

1) Has anyone else experienced this?
2) Is there a way to turn off this insane behavior?
3) Have the people responsible been punished?
4) If not, can I help?

Brian



BugSentry needs beta testers!
www.bugsentry.com

 

[Ken Halter]

Has anyone else observed this:

1) Take a project that contains a reference to a dll.

2) Remove said dll from the original location.

3) Build project.

Instead of failing at compile time, as any sensible compiler should, we
see Visual Studio looking around and finding another dll of the same
name to replace the missing one. In every case, this causes a
versioning conflict at runtime instead of breaking on compile.

1) Has anyone else experienced this?
2) Is there a way to turn off this insane behavior?
3) Have the people responsible been punished?
4) If not, can I help?

Brian

fwiw, this is just about exactly what VB6 does and it's the reason I tell
people..... when planning to break compatibility, unregister any existing
copies, optionally Zip them up for safe keeping and delete them. If they're
not deleted, VB6 "thinks" it's doing you a favor by finding and
re-registering them. Huge PITA if you're not ready for it.