Catching the absence of a DLL

[Steve Terepin]

I've got a Managed C++ wrapper class that calls some functions that talk to
a hardware data acquisition card, via a LIB supplied by the vendor. The
calls ultimately go through to a DLL, which is installed in the System
directory. Now, everything works fine on the machine that actually has the
hardware board present, and has the DLL installed. But I also want to run
this code on my laptop, and I'd prefer not to clutter up my system directory
with that hardware-specific DLL. When I run up my Test app, which creates an
instance of the Managed wrapper class (which is in its own assembly) it
collapses with a 'FileNotFound' exception - complaining that my Managed
wrapper assembly (or one of its dependencies) is not present. Presumably the
CLR is trying to load the assembly that contains my managed wrapper, and
falls over because the required DLL (used by the LIB routines I'm calling)
cannot be found. Fair enough - except that the exception is getting thrown
right at the beginning, before I event attempt to create an instance of my
managed wrapper class.

What I'd really like to do is catch this exception somehow, and substitute a
software simulation of the hardware card when the real hardware isn't
present. Any ideas ?

[William DePalo [MVP VC++ ]]

"Steve Terepin" <st***@terepin.freeserve.co.uk> wrote in message
news:#2*************@TK2MSFTNGP10.phx.gbl...

I've got a Managed C++ wrapper class that calls some functions that talk to a hardware data acquisition card, via a LIB supplied by the vendor. The
calls ultimately go through to a DLL, which is installed in the System
directory. Now, everything works fine on the machine that actually has the
hardware board present, and has the DLL installed. But I also want to run
this code on my laptop, and I'd prefer not to clutter up my system directory with that hardware-specific DLL. When I run up my Test app, which creates an instance of the Managed wrapper class (which is in its own assembly) it
collapses with a 'FileNotFound' exception - complaining that my Managed
wrapper assembly (or one of its dependencies) is not present. Presumably the CLR is trying to load the assembly that contains my managed wrapper, and
falls over because the required DLL (used by the LIB routines I'm calling)
cannot be found. Fair enough - except that the exception is getting thrown
right at the beginning, before I event attempt to create an instance of my
managed wrapper class.

What I'd really like to do is catch this exception somehow, and substitute a software simulation of the hardware card when the real hardware isn't
present. Any ideas ?

Chances are that the library supplied by the vendor is an import library.
When you link an application against an import library, the addresses of the
functions that it exports are not "resolved" until your application is
loaded. That address resolution can't happen until the DLL is loaded and its
base address is determined which is what ultimately determines the addresses
of the exports.

There are, I think, two ways to go.

One would have you not link against the vendor's import library. Rather you
load the DLL at runtime with LoadLibrary(). For every export in the vendor's
library that you need to call you would call GetProcAddress(). Armed with an
address, you can call the vendor's functions through a pointer. You can even
go so far as to build a "shim" DLL. That is a DLL which has the same number
of exports, each with the same calling convention. Your code would call
these shimmed functions. It would be the job of the functions in the shim to
either call the vendor's functions where his DLL is available or your
emulation.

Another option is, I think, to use a technique called "delayed loading".
With it, the complier and linker can be told to inhibit the loading of a DLL
at process activation. At runtime you would need to determine whether the
vendor's DLL is available, and if so, just call it. At that point, the delay
load mechanism would be used to load the DLL and obviate the need for calls
through pointers. If not available, you would need to call your emulation.
If you want to pursue this route check the docs for the meaning of the
/DELAYLOAD option and search the MSDN-CD or at http://msdn.microsft.com for
more info, especially the articles written by Matt Pietrek and John Robbins.

Regards,
Will

[Steve Terepin]

Many thanks - /DELAYLOAD does the trick nicely. Perfect :)))

S.

"William DePalo [MVP VC++ ]" <wi***********@mvps.org> wrote in message
news:um**************@TK2MSFTNGP12.phx.gbl...

"Steve Terepin" <st***@terepin.freeserve.co.uk> wrote in message
news:#2*************@TK2MSFTNGP10.phx.gbl...

I've got a Managed C++ wrapper class that calls some functions that talk to

a hardware data acquisition card, via a LIB supplied by the vendor. The
calls ultimately go through to a DLL, which is installed in the System
directory. Now, everything works fine on the machine that actually has the hardware board present, and has the DLL installed. But I also want to run this code on my laptop, and I'd prefer not to clutter up my system

directory

with that hardware-specific DLL. When I run up my Test app, which creates an

instance of the Managed wrapper class (which is in its own assembly) it
collapses with a 'FileNotFound' exception - complaining that my Managed
wrapper assembly (or one of its dependencies) is not present. Presumably the

CLR is trying to load the assembly that contains my managed wrapper, and
falls over because the required DLL (used by the LIB routines I'm

calling) cannot be found. Fair enough - except that the exception is getting thrown right at the beginning, before I event attempt to create an instance of my managed wrapper class.

What I'd really like to do is catch this exception somehow, and

substitute a

software simulation of the hardware card when the real hardware isn't
present. Any ideas ?
Chances are that the library supplied by the vendor is an import library.
When you link an application against an import library, the addresses of

the functions that it exports are not "resolved" until your application is
loaded. That address resolution can't happen until the DLL is loaded and its base address is determined which is what ultimately determines the addresses of the exports.

There are, I think, two ways to go.

One would have you not link against the vendor's import library. Rather you load the DLL at runtime with LoadLibrary(). For every export in the vendor's library that you need to call you would call GetProcAddress(). Armed with an address, you can call the vendor's functions through a pointer. You can even go so far as to build a "shim" DLL. That is a DLL which has the same number of exports, each with the same calling convention. Your code would call
these shimmed functions. It would be the job of the functions in the shim to either call the vendor's functions where his DLL is available or your
emulation.

Another option is, I think, to use a technique called "delayed loading".
With it, the complier and linker can be told to inhibit the loading of a DLL at process activation. At runtime you would need to determine whether the
vendor's DLL is available, and if so, just call it. At that point, the delay load mechanism would be used to load the DLL and obviate the need for calls through pointers. If not available, you would need to call your emulation.
If you want to pursue this route check the docs for the meaning of the
/DELAYLOAD option and search the MSDN-CD or at http://msdn.microsft.com for more info, especially the articles written by Matt Pietrek and John Robbins.
Regards,
Will