CODEWITHSUNDEEP
.netvb.netvb6
TylerReid
TylerReid

Reputation: 481

Debugging in VB6 that references .Net dlls doesn't work but running .exe does

I am doing maintenance on an old VB6 application that is part of a much larger and newer software system, and when I try to debug the code in the visual basic 6 IDE, the app crashes whenever it tries to instantiate a new object from any referenced VB.Net dll.

The error message is:

Run-time error '-2147024894 (80070002)': Automation error The system cannot find the file specified

This sounds like the references are wrong, but when I run the .exe file everything works and my changes are reflected. Right now my option is to just create a lot of message boxes to debug, and I have tried removing the project references and re-adding them as well as re-registering all the dlls as well as the usual Google/StackOverflow searches.

Am I doing something wrong, or is this crazy debug method just the fate of programmers working with ancient tech?

Upvotes: 2

Views: 1232

Answers (1)

Hans Passant
Hans Passant

Reputation: 941307

The VB6 debugger doesn't work at all like other debuggers you might have used. It doesn't actually start your EXE, it is VB6.EXE that is the executing program. The debugger wires itself into the p-code execution engine.

This has several consequences, the most important one that dogs you here is that the CLR will look in the wrong place for any dependent assemblies. It first looks in the GAC, next in the probing path for the EXE. Which normally is the same directory as where the EXE file is stored. You can see this going wrong with Fuslogvw.exe

The ugly workaround for this is to copy the DLLs to the VB6.exe install directory so the CLR can find them. In general, [ComVisible] components should be installed in the GAC so any client program that uses them can find the DLLs. That's quite ugly too when you do this on your dev machine and busy testing and editing your code, you're bound to forget to update the GAC copy and lose an hour of your life wondering why your changes are not effective. The possibly sanest thing to do is to use a Post-build event and xcopy the DLLs to the VB6.exe install directory so there is never a mistake.

Upvotes: 5

Related Questions