[RESOLVED] What would cause a dynamic link library to no longer be found by my visual basic prog

[gjon]

My program used to run on my system just fine until I removed some other applications. Then the proggy was giving me a runtime error. The funny thing is that once I installed visual basic 6 and added a reference to dao360.dll, or the Microsoft DAO 3.6 that the program then worked without error.

VB6 was never installed on this system before. The program worked just fine until applications were uninstalled from the system. What happened that caused the reference to stop working? Why did the program stop finding dao360.dll even though the program itself wasn't modified since vb6 wasn't installed?

THanks in advance.

[dilettante]

Many people use poor packaging for their applications.

One ugly "trick" is to just place libraries needed "next to" the EXE (same folder). Then on first run the VB6 runtime finds the library (DLL, OCX) and registers it there. When that program's folder is removed the orphaned refrences exist in the registry but the library has been removed.

This breaks other applications and prevents new installs from putting the library(ies) back in place because they appear to be installed already. I assume that installing VB6 itself resulted in it "force installing" its standard suite of component libraries.


Proper Windows installers maintain global usage counts for shared libraries. When a new "user" (application) is installed the count is incremented. An uninstall decrements the count, and if it goes to zero the library is unregistered and removed. Sadly many people insist on using package/install tools that don't follow the rules or make up their own rules.

Sometimes this can be detected during an uninstall and the user sees a prompt like "xyz.dll is a shared library that may be in use by other programs, do you really want to remove it?" Again, many shabbier installer technologies don't perform such checks but just remove all dependencies.

This tends to be a bigger problem with setups based on user-edited scripts of install/uninstall actions. An informed and conscientious package developer can create packages that are safe, but in the hands of amateurs "time bombs" can be created.


We now (Win XP+) have assembly isolation to safeguard our applications against other misbehaving installers. Not everyone uses the technique however. It has limitations of its own and a lot of people seem to be unaware of what has changed in the past 9 to 12 years of Windows progress.

[gjon]

Thanks for the explanation. Well done.