LabVIEW
The Installer Application can't find the dll-library
Solved!
Hello everybody,
I prepared an Installer of the application for the costumer, but the application doesn't find the dll-Library. The Installer installs the application files and a Folder, where the dll-Library is. The Directory structure is the same like the application on my Computer and the path to find the library is relative to the application directory.
If I copy the application folder somewhere on my computer, the library can be found. But if the installer installs the application folder in the costumer computer, this installed application can’t find the library.
I hope, someone can help me. Thanks in advance!
PS: I attached the VI-File from the application and the dll-Library
If the DLL path is correct another reason a DLL can not be loaded could be dependencies that are not installed on the specific computer. This could be custom low level DLLs that your interface DLL needs such as specific device drivers for the hardware in question.
Generally you should NOT distribute driver DLLs such as for your PCAN interface directly inside your app but run the official installer from the hardware manufacturer to install the drivers on a specific computer. Such drivers almost never only consist of the user space DLL alone but also require device drivers and support libraries to be installed.
And if it is not a driver DLL that you use you still have the situation that they always reference at least the C runtime library too. And that is specific to the C compiler version used to compile that DLL, so in addition to your DLL you also need the according C Runtime Library Support installed on the target computer which the DLL installer should take care of.
If you enter a full absolute path in the Call Library Node, LabVIEW will attempt to load the DLL from that path. The application builder will in that case also decide to include that DLL in the application build (and by default put it in the data subdirectory inside the application). The application builder will adjust the path inside the Call Library Node to point to the correct location relative to the VI path inside the executable too.
Now if you only specify the DLL name itself without any path or if LabVIEW was not able to load the DLL with the absolute path specified in the Call Library Node (either because the DLL doesn't exist at that location or because Windows refuses to load the DLL because it can't find a dependency of that DLL) then LabVIEW will attempt to tell Windows to call the DLL with just the name only and in that case the Windows search path criteria will apply.
When told to load a DLL by name only Windows will attempt to do following for the DLL and any dependency that DLL may have:
1) See if the DLL is already loaded into the process, if so use that one
2) Search the application directory (that is the directory where the exe file is located that started the current process).
3)The System Directory
4)The Windows Directory
5)Search the current directory (that is a process global directory that can be changed by several operations in Windows. When the process starts it is usually initialized to the application directory. Calls to the SetCurrentDirectory() API can modify that as well as the Windows file dialog does set this to whatever directory it is in whenever it is dismissed with any other operation than cancel. As such this directory is utterly unreliable to use.)
6) All Directories listed in the PATH environment variable
This specifically does not include the directory in which the referencing DLL is located!!!!!
What quite likely happens in your case is that your main DLL has other dependencies that you have copied also into the same "data" directory as your main DLL.
- LabVIEW tells Windows to load that DLL and Windows attempts to load it but can't find one of those dependencies (as it is not in one of the standard directories it will search).
- Windows fails the load informing LabVIEW that the DLL could not be loaded. Unfortunately there is no easy way to find out why the load didn't succeed, just that it didn't succeed.
- LabVIEW prompts the user to find that DLL which is of course is there using the Windows file dialog.
- The user selects the file and dismisses the file dialog
- The Windows file dialog automagically updates the current directory to that directory
- LabVIEW tells Windows to load that DLL with the "new" path selected by the user
- Windows loads that DLL and when now coming across those dependencies the DLL needs case 5) in the above search order kicks in and suddenly it works (until your app would display another file dialog to let the user for instance select a measurement file or something and boom the current directory is updated again and Windows wouldn't be able to load that DLL anymore if it wasn't already loaded!
For solving this for your built application you have really two options:
1) If the DLL comes with an installer use that one for the target computer too. It will normally install all necessary files into locations that allows Windows to find them.
2) If such an installer doesn't exist (most likely because the developer was lazy) you have to make sure that those dependencies are copied into your root directory for your executable. Easiest way is to add a custom destination folder to the build spec that points to that directory an assign that destination to all such DLLs. I usually also assign this destination to the DLLs the application builder does automatically include to avoid having DLLs in two different locations inside the application directory.
