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?

Thanks,

Brian

---

Clarification of Question by bselltiz-ga on 13 Apr 2004 05:32 PDT

PS - I am using Access 2002, so I need the code to work in that environment.

Sounds like a perfect application for side-by-side component sharing
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsetup/html/sidebyside.asp).

If you put a file with the same name as the executable, but with
.local appended to it, in the application directory, then Windows will
use "DLL/COM Redirection." In your case, the file would be
msaccess.exe.local (assuming that the Access executable is still named
msaccess in the 2002 version; it is in Office 2000), in the same
directory as msaccess.exe (c:\program files\microsoft office\office on
my machine).

You then put all of the .dlls and COM servers in this directory, and
Windows looks for the files in this directory before searching the
path or the location specified in the registry. Note that COM servers
still have to be registered with the correct GUIDs, but the path in
the registry doesn't matter.

This way, other apps continue to use the versions of components
specified in the registry or found on the path, and only Access uses
the local components.

Dumping files into the Office directory is a bit messy, but I thinks
it's a small price to pay.

Hope this works for you. BTW, it requires Windows 200, Windows 98 SE, or up.

- David

I followed your link and read up on this method. I could not get it to
work however. Could it be that I am actually calling an .mde and not
an .exe? I placed a file named MSACCES.exe.local and one of the dlls I
was worried about (one that I have created, no other apps on the
machine need this), both into the Office directory. I then launched
the app and checked the reference and it was still pointing to the
wrong place. I tried this on a W2K machine and XP also.
Any ideas?