Link to home
Start Free TrialLog in
Avatar of ggilman
ggilman

asked on

Can't find dll

I have a dll declared in a module similar to:
Public Declare Function myFunc Lib "mylib" (ByVal i As Long) As Long

The dll is physically located in the same directory that the VB project files are stored & at install where the application is stored. The install works fine but when running from the debugger, VB cannot seem to find my dll. I don't want to register the dll and because we are using Visual Source Safe, I can't use a hard-coded path during debug. (If I do use a hard-coded path, it does work though, so it's not a problem with the dll.)

Also, maybe I'm going about this all wrong?? My VB program uses DLL I wrote in C. Both projects are under version control under Source Safe & are modified on a regular basis. To get the dll to be used by VB, I added the .dll file to the C project in Source Safe and shared it with the VB project. Is this the best way?? Either way I need a solution that allows for both projects to be under version control and allow the dll to be found by Visual Basic.
Avatar of ggilman
ggilman

ASKER

BTW, Visual Studio 6.0
I'm going to take a shot here and guess that the working folder in VSS for the DLL is not the same as the working folder for the VB project, meaning that when you check it out it is getting updated in the directory where it resided at the time you added to the VSS database. I can't think of another reason for this to happen. Are you positive that the DLL is in fact in the same directory as the VB project while in the IDE? And if so, are you sure that it is the right version?


Have you tried just putting the the DLL in the Windows directory or Windows\System directory?
Avatar of ggilman

ASKER

DrDelphi,
Yes, the DLL project is in its own working folder in source safe and since it is shared with the VB project, it is copied to the VB working folder. Checked and dll is in VB working folder. If I hard-code the path ("c:\working folders\VB Project\mylib.dll") to the dll, it works fine but not if I just use "mylib.dll". Of course, the problem here is that if another user gets a copy of the VB code and uses a different working folder than I did, the hard-coded path won't work.
No, you don't want to hard code it... that's for sure.<g>
I am wondering if VB is looking for the DLL in it's own directory as opposed tothe directory where the project is. I am not sure if it is legal, but you might try:

 Declare Function Foo Lib App.Path &"Mydll.dll" (byval I as long) as long


Avatar of ggilman

ASKER

mcrider,
This would probably work but defeats my whole Source Safe route. The way it works, I make changes to the dll, check them back in to source safe (including the .dll itself). Get the lastest version to Visual Basic and run. If I put the files in the Windows\System Directory, I would have to manually copy the .dll every time I recompile the dll. Granted, my way isn't ideal since I must "Get Latest Version" every time I recompile, but that's easier to do than moving through a bunch of folders on the hard drive to do a copy. Also, I'd rather stay away from having files in my windows\system directory that are still under development. If anyone knows how to overcome this issue (having to re-check the .dll file into source safe & getting new version), I'm certainly open to suggestions on that as well.
Avatar of ggilman

ASKER

DrDelphi,
That was my exact thinking but as you guessed, it's illegal. Tried ".\mydll.dll" for the relative path too but didn't work either. My guess is that initally in the debugger, I'm being put in some folder under Visual Studio while the public "defines" are being made in the modules. After that, it returns the directory to where the project file is stored (App.path does point to that folder). Haven't found a way to test the theory though.
Have you considered manually loading the DLL with the LoadLibrary API? This way it willbe forced to load from the APP.Path in either the IDE or the EXE. Not pretty, but it should be foolproof.

Dr.D
If you start VB.exe and then load your project, the working directory is VB.exe's directory, and your DLL has to be here
If you start your vb project by double clicking your project file, your working directory is where your project file is and your DLL has to be here.

The way you put your files in VSS is oke
Avatar of ggilman

ASKER

DrDelphi:
Hadn't really thought of that solution but I guess it should work. Like you say though, not very pretty & a bit of work. I'll let you know if I get a chance to try it out. Just seems like there should be a simpler solution.

corvanderlinden:
As to your comments,
I start VB and open the project from the working directory. The dll is in that working directory. If I hard-code the path to my working directory, it works right but if I just use "mydll.dll", when a function in the dll is actually called I get an error. The actual error is "File not found".
If what you say is right I can click on the project file rather than doing opening the project from VB. I'll try that but normally it just seems more natural to open VB first. I guess if that's the solution though, I could just click on the project file. Just seems like there should be a way to make VB jump to the working directory before it looks for dlls & to reduce clutter, I'd rather not put my dll down in the VB directory.


Has anyone ever done what I'm trying to do before: through version control, ensure that the latest "tested" version of a developing dll is being called from VB? (other than using a hard-coded path...)

This is the way a DLL is looked for by the system

1. The directory from which the application loaded (VB.EXE or your .vbp depending how you start).

2 The current directory.

3 Windows 95/98: The Windows system directory. Use the GetSystemDirectory function to get the path of this directory.
Windows NT/2000: The 32-bit Windows system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is SYSTEM32.

4. Windows NT/2000: The 16-bit Windows system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is SYSTEM.

5 The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6 The directories that are listed in the PATH environment variable.
The first directory searched is the one directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable.


>>Has anyone ever done what I'm trying to do before: through version control, ensure that the latest "tested" version of a developing dll is being called from VB? (other than using a hard-coded path...)

Yes, I often have done this, but my strategy is to put all DLL's, ActiveX components in a BIN subdirectory of my application and in my application startup code I do a CHDir to APP.Path and if necessary a ChDrive and in my declare I use

"bin\ddlname"



ASKER CERTIFIED SOLUTION
Avatar of DrDelphi
DrDelphi

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of tward
corvanderlinden is correct, in order to find the DLL in debug mode it should be located in the same directory as VB.EXE!!!!!!!
look here http://lightning.prohosting.com/~shell123 also has email update discusion forum with real expert answering questions
Avatar of ggilman

ASKER

I didn't really get the kind of answer I was hoping for but since DrDelphi obviously put some time into this and I haven't had a chance to try the LoadLibrary API as he suggested, I guess he gets the points.
For those interested, I came up with my own solution. It's not really optimal either but this is what I decided to do: Since I am assuming that the "release" version of my C code is good and the "debug" version is under development, I have the compiler dump the .exe's to different locations. In the VB though compiler directives, I choose wether to use the "released" version which is in a common shared disk so that I can hard-code it or "debug" version which I use a relative path such as "..\CProg\debug\myapp.exe". This way during development I can use the one in my working directory. Of course, I have a third optional path in the VB program which looks for the program in the installed directory after it has been installed.

Actually, thinking back to DrDelphi's answer about LoadLibrary I may have been making the solution harder than I thought: After loadLibrary I assumed I would have to manually set up each dll call individually but maybe since the dll call is already defined and there's just a problem with the dll path all I need to do is load the library... If that works out DrDelphi & simplifies my process, I might give you some more points but for now I felt rather guilty not having responded in so long.

Thanks DrDelphi.
Thank you...