views:

97

answers:

3

I've written a C++ DLL that connects to a Sybase database using the native C library for Sybase. I can build and run the program on my C drive, and others can run it from their C drives, and everything works. But in some situations both my DLL and the Sybase DLL are located on the F drive instead of the C drive. In those cases my DLL apparently fails to load the Sybase DLL.

I'm a little unclear on how linking works, but based on my incomplete understanding my best guess is that the C-drive location of the DLL is what gets built into the final DLL, which is what causes it to fail when it runs from a different drive letter. Does that sound like a reasonable explanation? Any other reasons my DLL would fail to load the Sybase DLL when run from a different drive letter? Any idea how I can resolve this?

EDIT: Turns out this was the wrong question, but it led me in the right direction. The Sybase DLL uses an ini file to determine database connection details, and I had the path for that hard-coded to the C drive.

A: 

Is this .net and is the F drive a network drive? There are some security issues on some versions of windows when you do a copy of a .net exe to a network drive and try to run the code. The operating system won't let it run. I expect this is your problem.

Hogan
No, this is an unmanaged C++ DLL calling a C DLL. It's not a code access security problem.
John M Gant
I didn't answer the other part: no, F is a partition, not a network drive.
John M Gant
+1  A: 

Generally speaking absolute locations are not used inside DLLs. Only the name of the DLL is stored.

The places where system looks for DLLs are descrived here: http://msdn.microsoft.com/en-us/library/ms682586%28VS.85%29.aspx

Though it IS possible to load a DLL by absolute path - with a techinique known as run-time DLL loading - but I suspect not many programs do so.

EFraim
Run-time loading is useful when the DLL may not exist, or may not be loadable: for example, a program might use run-time loading of the Sybase DLL if the Sybase DLL may or may not have been installed.
ChrisW
@ChrisW: Yes, but even then you rarely use absolute paths.
EFraim
Thanks for the link. This helped me to rule out my original theory. Turns out I had a C-drive location (an ini file) hard-coded at one point in the data access code.
John M Gant
A: 

is the location that your DLL and the Sybase DLL are stored on the PATH ?

Liz Albin
The Sybase DLL is in PATH. My DLL is actually on a different server entirely but is being loaded dynamically using the full path and name. The executable that loads my DLL runs from a location that's in PATH.
John M Gant