Is there any downside to putting VB6 dependent files in app directory?

Question

Assuming that the Application directory is writeable and that HD space is not an issue, are there any downsides to putting the VB6 dependency files (msvbvm60.dll, etc.) in the .EXE's directory?

I've got the most up to date dependency files and I'm guessing MS isn't coming out with any new versions of those so I figure it's safest (in terms of DLL Hell, etc.) to just keep those files in my app directory where they won't be modified and (IFAIK) they'll be the first ones used by the app (before using ones in the System32 directory, etc.

Answer 1

This should be fine, I've had to do this in the past for a third party DLL I used in a VB6 project many years ago (we relied on a quirky implementation of a component to do something and later a "fixed" version was installed with a popular software suite). Though if its COM the regsvr32 install of the library may ruin your plan to avoid DLL hell.

Answer 2

It has been my experience that files like msvbvm60.dll, the various OCXs, have subtle dependencies that play havoc when you try to install in your own application's directory. Our solution was to track down all the dependencies and made sure that they were part of the install and handled correctly in accordance to Microsoft's rules.

In the 8 years since MS stopped developing VB6 we have experienced little in the way of DLL Hell. (about a half dozen incidents in over 500+ installations) and those were the result of the customer mucking around with Windows XP before we got there.

In short, any custom or third party stuff put into your application directory. The rest makes sure everything is included let it install into the system folder in accordance to MS's suggestions.

Answer 3

More in-depth discussion in this question: discusses various methods to force VB6 to load dependent files from another location, like .local files, reg-free COM, and DirectCOM.