Is there a way to force the VB6 IDE to unload libraries?

Question

When debugging a VB6 application, I have noticed that the VB6 IDE keeps any libraries loaded if they were used by the application being debugged. The library remains loaded between debugging sessions. This interferes with my debugging because unfortunately, one of our libraries (written in delphi) keeps state around in global variables and has significant initialization/termination logic.

Simplified example of the problem: I have a foo.dll with a counter inside it. I access this counter with the following declares in VB6:

Public Declare Function GetCounter Lib "foo.dll" () As Long
Public Declare Function IncrementCounter Lib "foo.dll" () As Long

The problem in this case is that the counter is not reset when I start a new debugging session. I would rather not write application or library logic to take this "recycled library state" scenario into account. I want to be able to start a debugging session with a clean slate.

Currently I force a library unload by restarting the VB6 IDE. Is there a better way?

---

edit: I played around a bit with invoking kernel32.dll functions to unload/reload libaries from the immediate window; this turned out to only be a good way to crash the IDE or cause random behavior. I should have expected that as the IDE has no way of knowing that it's original handle for the library has become invalid.

I have accepted AngryHacker's answer as I am now convinced that restarting vb6.exe is the only way to start a VB6 debugging session with a completely clean slate.

Answer 1

I've struggled with that for years back in the day, particularly when coding ActiveX DLLs for use with IIS sites.

The only real antidote I found was to keep the library loaded in a separate VB6 instance (assuming you have the control of the source). That way you could simply press the Stop button on the toolbar and the library would no longer be loaded.

Answer 2

You should look at a few things:

1. Make sure you are disposing of any class references by setting your local or global variables = nothing when your application exits.
2. When debugging, NEVER hit the end/stop debugging button. This just pulls the rug out from under the code and can sometimes leave things hanging in memory.
3. Don't use the End command in your application exit code (see point #2).