Call Library Function Node fails depending on run location

[russellb78]

I am calling a dll from a call library function node inside a LV Class.  If I run the VI from Windows Explorer then the call library function node executes successfully. However if I try to run the VI from a LV project then I get an error message saying the specified module can not be found.  

 

Anyone know what might be causing this issue?

 

Thanks,

 

Russell

[mje]

How are you calling the DLL? I imagine you must be passing a path to the Call Library Function node? Is that dialog something you generate or the DLL?

[russellb78]

Thanks for your response,

 

I have tried hardcoding the path and passing it into the DLL. It is working properly from the LV project today and I did not change anything. I know when I get this error I have to shutdown LV and run the vendor's VB example program before the error is cleared.  There is something strange with the way this DLL is interacting with LV. I am just worried because I am not getting consistent results.

 

Russell

[ned]

When you say "run from Windows explorer" do you mean that the project is not open in LabVIEW, and the only VIs that are open are the one you're running and its subVIs? If so, I wonder if you have some other VI in the project that's loading a conflicting library, either a different version of a library with the same name or a different version of some dependency. If you rename the DLL, does the problem go away? What about building it into an executable?

[russellb78]

Thanks for your response,

 

Answer to your first question - yes

Answer to your second question - haven't tried renaming the dll or built an executable yet. I am unable to reproduce the problem today.

 

Russell

[russellb78]

The problem came back and I discovered what was causing this issue.  There is another dll file that the vendor's dll is calling with a relative path.  In order for LabVIEW to find this other dll properly I had to place it into the same folder where the LabVIEW.exe is installed.  

[Rolf Kalbermatter]

The problem came back and I discovered what was causing this issue.  There is another dll file that the vendor's dll is calling with a relative path.  In order for LabVIEW to find this other dll properly I had to place it into the same folder where the LabVIEW.exe is installed.  

 

That is not a correct analysis and the solution is only one way to solve the problem. The real problem is not a relative path but simply the fact that your DLL depends on another DLL. No path is stored in your DLL to the other DLL, just its name. Windows when asked to load a DLL will scan the entire import list of that DLL and load any dependency of that DLL too. For that it looks in following locations:

 

1) It looks if the current process has already loaded a DLL with the same name, if so it is simply linked to the imports of the DLL currently loaded

2) It then looks in the same directory as the executable file of the current process

3) Next it will look in the <System> directory

4) Then in the 16 bit <system> directory

5) Then it will look in the <Windows> directory

6) Next is the current directory (that is the directory where the latest operation was done from inside the current process, that can be the double click to start the application or any file dialog box that is dismissed with anything but Cancel is selected, or an explicit call to the SetCurrentDirectory() API)

7) Last but not least it will look in any directory listed in the PATH environment variable

 

In Windows XP and earlier point 6) is by default placed between 1) and 2)

 

placing your secondary DLLs into the LabVIEW.exe directory is the safest location, but gets quickly a mess if you have more than one or two such DLLs. It is also a hassle to remember to include those DLLs into your application executable build and make sure they get into the root directory of your application.

 

The proper solution is to have an installer for your DLL that takes care about installing all dependencies correctly too, and that installer should be created by the supplier of your DLL.