From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

lvlibp dll dependencies

Hello,

 

I have a big problem when using my own lvlibp. We have an lvlib for a "home-made" tool that we (re-)use in many developments. Our intention is to integrate it in our development projects as an LVLIBP, with various advantages (compact code, protected source, clear "build" versioning for the whole library, and so on). Building the lvlibp from the lvlib works fine. However, we see that LabVIEW automatically includes all dependencies in the resource folder, like lvanlys.dll that is used in our source VIs.

 

Then when we want to use that lvlibp in a project, we of course get conflicting dll paths, as we obviously have other parts of the project code that also refer to lvanlys.dll (the one in Program Files/LabVIEW/resources). Then when opening the top VI, the dll from the lvlibp resources folder is always preferred to the "original" one, so that we are always asked to save VIs from .vilib to refer to this "new" path of the dll... It is impossible to work like this...

 

How can you actually use lvlibp's that refer to common LabVIEW dlls without having these conflicts when integrating the resulting lvlibp into a new LabVIEW project ??? Did I miss something or are these LVLIBP just unusable in this (very general and common) case ?

 

Thanks,

 

Vincent

0 Kudos
Message 1 of 2
(3,232 Views)

Vincent,

 

All build specifications (not just Packed Project Libraries) will copy DLLs to the build location if the Call Library Function node references the DLL by path (which is the case in the example VI that you sent).  If the CLF node references the DLL in name only, it will not copy the DLL, but should expect the DLL in the system search path.

 

I do not recommend that you modify the LabVIEW VIs and their CLF nodes, as this could cause unexpected behavior.  I recommend either of the following options:

 

1.  Keep the VIs in a normal library, but set it to private and password protect the library.  This should prevent developers from viewing the source code.

2.  Add the DLL to the project.  In the build spec, check the option to rename the file under Source File Settings. This should prevent any linking issues.

 

I apologize if this is inconvenient, but hopefully the options above are helpful.

Message 2 of 2
(3,149 Views)