VS 2005 guesses at DLL

  • Thread starter Thread starter Brian Begy
  • Start date Start date
B

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
 
Brian Begy said:
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
Click to expand...

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.
 
Back
Top