excutable cannot find dll

[jgar5427]

In my workstation I build an executable, "MUTS Rev L3.1", in LabVIEW 8.6 However, after the build folder "MUTS Rev L3.1" is installed on a different PC on the test floor and the operator clicks on the executable icon the application launch is stopped because it cannot find "phidget21.dll" Once the file is located in the build folder the lauch operation continues and the application gets loaded. How can I prevent the launch operation from prompting the operator to find phidget21.dll?

Best regards,

Jaime Arevalo

Test Engineer

Micropac Industries

[JÞB]

in your build spec mark the dll as "Always encluded" and set its destination to the same folder as the exe.

[billko]

Also, something only perpiherally related to your issue - but equally important: Sometimes there are legal issues involving the inclusion of dlls into your release.  Make sure you follow the fine print.  This is especially important if you work with government contracts.

[jgar5427]

Jeff, thanks for the input. Indeed, marking the .dll as "always included" during the executable build works. What I am trying to accomplish is to have the icon I created for this application to launch the LV application rather than using a shortcut to the application. When I pin the icon to the Start menu, double clicking on it launches the app w/out any issues. However, if I chose to move the icon to the desktop then, when the app is being loaded, it stops to search for a servomotor dll. It searches for this dll in C:\Documents and Settings\PCname\Desktop\instr.lib. The operator needs to access C:\Documents and Settings\PCName\ Desktop\build folder name\data to find the dll in question (phidget21.dll). Once this is done the LV app launches without any issues.

I am tryingto find a way to place on the desktop a user defined icon (not a shortcut), associated with the LV application exec. Then the floor operator only needs to click on the icon to launch the LV application. I am not sure if this can be done easily on Windows XP. For now I will continue using the shortcut on the desktop to access the app.

BTW, we purchased the servomotor phidget21.dll when we purchased the device from the vendor (Phidgets)

[JÞB · Accepted solution]

am tryingto find a way to place on the desktop a user defined icon (not a shortcut), associated with the LV application exec

---

Not an easy task when IT departments get involved.  You'll need some pretty powerful admin priviladges to access All Users\Desktop and thats not a very nice place to put an application. 

[jgar5427]

Indeed, IT has some strict rules about deploying LV apps. Nevertheless, I will find a way to implement this approach in my free time.

[WNM]

I had this same problem today and went looking for answers and found this topic/discussion.  I tried the suggestions presented here for fixing the problem but I continued to get a message saying that the call-Library function could not find the DLL, even though it was sitting in the folder right next to the EXE file. 

In my case, the root cause of the problem was the following:

VI "AAA" calls DLL "BBB" and "BBB" is the DLL that was reported as not found. Invisible to me (and LabVIEW apparently) the DLL "BBB" in turn calls another DLL, "CCC".  The application builder was smart enough to know that BBB needed to be included in build of the executable but it was not smart enough to pick up on the fact that BBB called CCC  and CCC got left out of the build.  To compound the confusion, when AAA was run, it incorrectly reported that BBB was missing, when it was really CCC.

The bottom line here is to include (manually, if need be) all the DLLs that are in the call chain even if LabVIEW does not acknowledge that they are all used.

[rolfk]

LabVIEW can’t know that BBB calls also CCC. In order to do that it would need to parse every dll for dependencies and try to mimic the Windows module loader search strategy which has differences depending on Windows version, local policy settings, environment variables and other possible things only a few programmers in Redmond (or India) know.

All LabVIEW can do is to tell Windows to load the dll it knows about and if Windows returns a failure to conclude that somethjng is wrong. In ancient times (LabVIEW 5 or so) it attempted to determine if it was the dll itself or some other thing by analyzing the error code and other information from the error message generated by the losder but that was relying on information Microsoft never documented to be exactly like this and promptly got changed in later Windows versions.

Supposedly they could stat() the dll path after a failure and conclude that the file is actually there but that still won’t tell if that file is an actual dll or just a dummy file with that name.

The only practical improvement I could see is to improve the error message (if it doesn’t already mention it) to:

The dll “bbb.dll” could not be loaded and either itself or one of it’s dependencies might not be present on the system”

For all practical purposes however this message will be for most users just as helpful as saying that “bbb.dll” couldn't be loaded and to contact the application programmer. 😀

The bottom line really is that if you have dlls with dependencies, that dll should always come with an installer which takes care about proper installation on any particular system with all the dependencies and to include that installer with your application. Trying to determine all the components needed by a dll yourself is not inly cumbersome but also failure prone as it may depend on various factors such as Windows version and other installed software on the target system.