LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dll in abview Project

Hi,

 

i have received a Labvieww project in which some dependencies are strange since on my computer the DLL are under /Windows/System32, while in the project are directly under C:. I have tried to adjust the thing but it worked only for one DLL (DAQNavi_LV.ddl) with the result of showing it two times (i have only specified the path in the function node which uses the dll). I can't remove the wrong dlls and if I try to refresh the dependences nothing change (moreover i have no access to some visthat uses nilvaiu.dll). How can i solve the problem since when i built the EXE somo dependencies will miss? 

 
 

Dll.PNG

 

thank you for the help!

 

best regards

 

Zuc

0 Kudos
Message 1 of 6
(165 Views)

The application builder will include most dependencies automatically and if one is missed you can add it to the "always include" list in the build specification.

 

(There is no C: in a project, the hierarchy is virtual and has little to do with location in the file system.)

0 Kudos
Message 2 of 6
(142 Views)

Hi  ,

it's fine that the Folder tree can be different from the project organization, the fact that no path is shown for the dlls is leaving me with some doubts. especially if i build an exe to deploy on a target machine. How can i check if the paths are all ok? 

 

Dllpath.PNG

 

Best Regards,

Zuc

0 Kudos
Message 3 of 6
(109 Views)

DLLs without any path in the project window are actually loaded from one of the relevant search locations that include system32 and windows directory. You should also NEVER enter a full path to any such DLLs in the Library Path inside the Call Library Node. The fact that you only include the library name without any directory information is a special indication to LabVIEW that it is a system library that should not be included in an application build. If you enter the full path you not only can confuse LabVIEW/Windows (when the project is loaded on a different computer) but also will cause the LabVIEW application builder to include that DLL into the build as a private library. And if that happens with DLLs such as kernel32.dll or advapi32.dll or anything similar, Windows completely looses it and causes rather sooner than later that the process is terminated due to some protection fault error and under extreme situations the entire Windows system can get unstable. 

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 4 of 6
(93 Views)

Hi rolfolk,

the problem is related to the Exe build. the AdvLvDaq (in System32 by installation of the driver) is seen as a dll to save in the support folder, DAQNavi_LV.dll, otherwise, isn't saved in the support folder and the exe have problems at the start up. observing the differences between the DLLs i was trying to understand the best practice to manage third part dlls and projects.

 

dll.PNG

 

Best regards,

Zuc

0 Kudos
Message 5 of 6
(59 Views)

If the application builder includes the DLL in the build it is because one of the Call Library Nodes contains a full path rather than just the library name. If that DLL is installed in the system32 folder, this is an error of that Call Library Node.

You need to find the respective Call Library Nodes (search with text in the project) and change the Library Path to the name only.

 

DLLs from system32 are NOT to be installed by an application directly but by the relevant driver installer!

Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 6 of 6
(54 Views)