Applications Referencing the ADOX Library Fail Under Windows Vista
Provided by: Luke Chung, FMS President
Your existing Visual Studio .NET or Visual Basic
executable, or compiled Access application (MDE or ADE) is running fine
on Windows XP. However, when your users upgrades to Vista, it no longer
works -- or portions of it fail. Why?
After considerable head-banging, we discovered one cause
of this is due to a compatibility problem with the ADOX library in
Windows XP vs. Vista. (There may be other reasons, but this is what we
found so far).
The ADOX Library is the Microsoft ADO Ext. 2.7 for
DDL and Security. You can specify it under the library references
for your project:
In Windows XP, the version is between 2.5 and 2.8. If you
use the oldest version, it automatically adjusts if the user's machine has a
later one.
In Windows Vista, ADOX version 6.0 is available.
Unfortunately, the .NET/VB/Access executable does not automatically upgrade
to this version. However, it does not completely break either -- the
IsBroken property of the reference is False. Nonetheless, indications of a
broken reference appear. For instance, in Access, queries that use VBA
functions no longer work.
Workarounds
There are two ways to work around this problem, neither of
which are ideal:
Late Binding
Rather than referencing ADOX as a library, reference it as
an object in your code when it runs. Of course, this is less efficient and
prone to errors since the compile time checking and Intellisense are lost.
Create Separate XP and Vista Builds
Create your executable in Vista with the new version of ADOX,
and give that version of your program to people running Vista. That version
won't run on Windows XP, so you'll need to maintain a separate build for
that and install accordingly. Of course, this doesn't work when an existing
machine is upgraded to Vista.
Of course, neither of these options work if you don't
have the source code. Even if you did, creating a new build is prone to
all sorts of other errors related to having the other library
dependencies correct, the proper ActiveX controls installed, and the
standard challenges of dealing with DLL hell for a legacy application.
Hopefully, the folks at Microsoft will provide a patch soon
to address this failure of backward compatibility, so we don't have to
change our executables. In the meantime, stick with Windows XP for these
applications. Good luck!
Return to the tips page
|