VBA References - DLL Hell

Posted on 2004-04-14
Medium Priority
Last Modified: 2012-06-21
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!


Question by:bselltiz
  • 4
  • 4
  • 3
LVL 10

Accepted Solution

Kavar earned 1000 total points
ID: 10827640
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
LVL 27

Expert Comment

ID: 10827811
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.


Author Comment

ID: 10828032
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.
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 27

Expert Comment

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

LVL 10

Expert Comment

ID: 10828393
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

Author Comment

ID: 10829443
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...
LVL 27

Expert Comment

ID: 10829474
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.


Author Comment

ID: 10835824

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?
LVL 10

Expert Comment

ID: 10835871
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

Author Comment

ID: 10836024
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.
LVL 27

Assisted Solution

Dabas earned 1000 total points
ID: 10836952
> 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.


Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Monitor input from a computer is usually nothing special.  In this instance it prevented anyone from using the computer.  This was a preconfiguration that didn't work.
In this post we will learn different types of Android Layout and some basics of an Android App.
Introduction to Processes
Starting up a Project

807 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question