• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 9522
  • Last Modified:

VBA References - DLL Hell

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!


  • 4
  • 4
  • 3
2 Solutions
Windows 2000 and above are supposed to support dll versioning, the problem with it is, if your using something like excel and some other application is using an excel object at the time, the different dll will appear to load but it will infact be a reference to the currently loaded one.

Your best bet...

Use late binding, it will be a tiny bit slower, but you won't go into dll hell...

an example.

If you include the msaccess9.0 type library, a number of functions will work for 10 and 8 clients, but some won't, whats worse depending on which one your using, you'll have no Idea what failed!!!

so instead of
dim access as msaccess.application

dim access
set access=createobject("Msaccess.Application")

then on program startup, do an object check....

for every different createobject() that you do in the application,
do this...

Function TestObjectCreation(ObjectClass as string) as boolean
on error resume next
dim s
set s=createobject(objectclass)
if err.number=0 and isobject(s) then
end if
end function
Hi bselltiz:
NOt sure, but possible solution. I know I used this approach, but that was a while ago and systems were of the Win95/98 kind.
Still... what can you lose but give it a go?

I have the feeling that an application will first look for the dll and ocx in App.Path, then if it is not found there, it will search the registry.
In short, place the dll and ocx files in the same folder as the executable.

As to the 1500 points, that contravenes the membership agreement. 500 is the maximum, otherwise we would have points inflation.

bselltizAuthor Commented:
Kavar - I'm not sure I understand, maybe I should be more specific on the DLLs I'm having problems with:
They are, msadox.dll, dao360.dll, owc10.dll, msado25.tbl and 3 more that I beleive are not modifiable? They are stdole2.tlb, msacc.olb & the Visual Basic for Applications dll (whatever it's name is)
I want to supply copies of these on install and make sure my references point to my copies no matter what.
Is this possible?

Dabas - I can't rely on the default behaviour of windows to find the file because if they already have an older version then I might not be able to rewrite it....permissions wise I mean - plus I'm pretty sure that I tried going by Microsoft's supposed search order and it didn't always search in the order they said it would.
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

>  and it didn't always search in the order they said it would
What else can one expect from M$?

msado25.tbl is a type library, if this is a required file, you are using early binding, because of this you are fixing yourself to a version with ADO.  Your best bet is to use late binding and simply including the minimum version of ado with your install package.  (The visual studio packager will do this for you)

if you are using late binding (createobject ...)
then the Function I provided earlier can be used to determine whether or not you will be able to continue or of the program should (a) halt or (b) upgrade dlls
bselltizAuthor Commented:
Kavar - I hate to sound like a novice here....but I guess I am. I have never looked into early and late binding. Can you provide an overview of the concepts behind it? I ask because this is a very large app and making a major change is a very very big undertaking. (FYI - I use ADO in most areas but also do a little work in DAO). I need to be sure it will work. I am very willing to do it and learn if it will work.

Thanks for the help guys...
Good news
To change from 'early binding' to 'late binding' not many changes are needed. Probably a few search and replace will do.

Example of early biding:

Dim rs as  ADODB.Recordset
Set rs = New ADODB.Recordset

Same code with late binding:

Dim rs
Set rs = CreateObject("ADODB.Recordset")

In the first instance, the binding is done "early"... at compile time on your development computer.
It often is preferrable, as it will save on time and resources

In the second instance, the binding is done "late".. at run time on the user's computer.
Your system might be using ADO 2.6, his system might be faltering because he only has ADO 2.1 installed or active.

By using late binding, it does not matter what he has, as long as it is capable of "understanding" ADODB.Recordset.
It probably is the solution you are looking for.

bselltizAuthor Commented:

I was hopefull that would solve my issue - but I came up with a problem. 2 of the references are required at start up by Access or VBA (I'm not sure which). They are VBE6.DLL and MSACC.OLB. My code requires the newest versions of these to run correctly. Am I correct that early binding is the only way to go with these?
vbe6.dll is a visual basic runtime, distribute the most recent of these and it is highly unlikely you will break anything

msacce.olb is part of the type libraries for msaccess (unless I am totally uninformed)
You need to remove this reference if you want to use late binding
bselltizAuthor Commented:
I don't even care if I break anything anymore - I have to get this done :->

If I distribute vbe6.dll with my install, how do I set the reference if I don't know if they already have the file. and the one they have will be used instead of mine? Do I delete all of the vbe6.dll files on the machine, copy my version to the path I had the file stored at during the time of development on my machine and hope the reference holds?

as far as msacc.olb, my app requires the latest version to run correctly. I was only looking to use late binding to solve my versioning conflicts. I would rather use early binding if I could find an alternative to the dll problems.
> copy my version to the path I had the file stored at during the time of
> development on my machine and hope the reference holds?
In theory, you should not be having this DLL Hell with VBE6 and MSACC.
ARe you using the PDW to create a setup file to install on the user's system?
I have been installing programs that use both VB and Access for years, and have very seldom encountered problems like you are describing. The setup program created by the PDW makes sure that only later versions are installed.
Copying just the dll CAN create the problems you are talking about. Quite a lot of DLL files depend on other DLL files, and it is hard to know if you have covered all of them.

Last point: Have you tried installing different versions of MDAC? This also often resolves DLL Hell problems.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

  • 4
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now