VBA References - DLL Hell
Posted on 2004-04-14
I’m having a problem (that after much reading seems like a common one)
with references in my vba app. I will be distributing a mde to any
number of workstations running w2k or xp. I need to have my app use
the dll’s and ocx’s that I copy to the machine during the setup
program. I would rather not modify the user’s machine but it seems
after looking into it that I may not have any choice other than to
overwrite their files, either older or newer. I say this because the
most important app on the machine will be the one in question so if
something else stops working the user would rather lose that program.
This is what I think needs to be done?
Go through a list of the references (that I maintain) (ex – msadox.dll)
Modify the registry to point to the version that I have copied to the
machine instead of pointing to the version already installed.
Change the reference to point to my file if anything has changed.
If this is not the correct method I am will to use another. The goal
here is to not have the app stop running because of library conflicts.
It can’t happen at the time of install or down the road either. So I’m
guessing either perform a startup check every time the app starts or
have a small program separate from the app available that can be run
to fix any problems?
I have tried DLL/COM redirection and could not get that to work either.
I placed a file named MSACCESS.exe.local in the office directory along with one of the dlls in question but it did not work.
I will triple the points for a fully explained answer - that's 1500 points!