LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Including DLLs in a PPL as a relative path

Can DLLs be included/referenced in a PPL as a relative path, as is the case LabVIEW based files?

 

When I build a PPL containing DLLs, it copies them to the destination directory correctly and links to the new location, but the path is absolute. Therefore, when I move the PPL and DLLs to a new location (relative paths remain the same between PPLs and DLLs) the PPL fails to find the DLLs.

 

I'm guessing this is why the DLLs are also not automatically included during an executable build that references the PPL. The the 'Always include' section of the build section contains the PPL, which by inference should include the DLLs as well.



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 1 of 10
(281 Views)

Another LabVIEW bug?

 

From the LV2018 Help file.

LabVIEW retains the links **relative** to the original filesLabVIEW retains the links **relative** to the original files

 

The result is the same with or without the checkbox selected. The help tooltip is also titled "Exclude DLL" instead of the new name.



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 2 of 10
(235 Views)

There is more to this than you show. I have done this and always enable the check box to exclude dependent DLLs in a build. But you may have other problems such as additional dependencies that your DLL requires. LabVIEW does not know about them and can't take care of them. If Windows can't find them it will fail the loading of the main DLL LabVIEW has requested to load, and LabVIEW will simply report to you that the DLL could not be loaded, possibly because it doesn't exist or isn't a valid DLL file. The error message is a bit misleading in this case but unfortunately there is no fool proof way to detect why the loading of the DLL was denied by Windows.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 3 of 10
(204 Views)

Thanks Rolf. I admit I could have been clearer. That's useful to know about the error messages and problems with loading - I just assumed it was due to LabVIEW itself not being able to find the files even before attempting to load them.

 

For clarity, here is one example:

PPL project

Project viewProject viewFiles viewFiles view

 

Built PPL unmoved

Project viewProject viewFiles viewFiles view

 

 

Built PPL after moving contents and dependencies (relative links remain intact)

Project viewProject viewFiles viewFiles view

 



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 4 of 10
(197 Views)

I've notice that the same thing also happens for other non-LabVIEW based files. For example a PPL containing just a text file and an image file.

 

It all linked correctly until the parent directory was moved (again relative links remained intact).

explorer_BCMtQ3MGQK.pngShareX_2Rb51F33vK.png



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 5 of 10
(187 Views)

Your driver clearly exists of multiple DLLs. LabVIEW only knows about the DLLs you explicitly call through a Call Library Node, nothing else. The fact that you include the other DLLs in your project does not mean a lot, although LabVIEW tries to do a few things to make them potentially available as long as you execute the code from within a project. But your built PPL is not executing in a project, but is fully standalone.

 

LabVIEW asks Windows to load your jeti_spectro_ex.dll for instance when you reference a function inside that DLL. Windows tries to load it and sees, look it also needs jeti_spectro.dll and looks in its well known DLL locations. -> Nada, nothing there. Beeep, sorry LabVIEW but I can't load the DLL you asked for. Bad luck, try something else! As far as Windows is concerned everything possible has been done and as far as LabVIEW is concerned it can't know and shouldn't even try to know if a specific DLL has potentially other dependencies. Such trickery would only cause more trouble sooner or later.

 

If your DLL you try to call from LabVIEW are not fully self contained (meaning they have other DLL dependencies) there are only two valid solutions.

 

1) Make the DLLs application private by installing them in the same directory as the executable file for your application.

 

2) Have a proper installer for your DLL files that installs them in a system accessible location so that Windows can find them.

 

This is not a LabVIEW failure but a Windows limitation and not one that was arbitrarily created. You do not want Windows to search all over the place for potential DLLs that might fit a dependency. That would be a paradise for any troyan or backdoor trying to inject malicious code into arbitrary processes and steal everything you have on your computer.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 6 of 10
(183 Views)

Hmm, unsure if it's Windows generating the error. Seems the paths are being stored as absolute when it would make more sense for them to be relative (based on the image and text file example above).
As though this is a PPL problem even before the DLL has been loaded into memory using LoadLibrary from Windows API



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 7 of 10
(181 Views)

PPLs are not meant to contain arbitrary file types. They are LabVIEW files to contain LabVIEW objects. While they may seem conceptually the same as a lvlib, they are not. A lvlib is an XML file that REFERENCES files on the harddisk as items. A lvlibp is a container that CONTAINS files that make up a library. They are presented to you in the project view in very similar ways but are very different things in reality.

 

It's similar as when you look at a ZIP file in Windows Explorer. It looks like a directory hierarchy since ZIP archives contain a directory hierarchy but it is something very different than a directory hierarchy on disk.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 8 of 10
(173 Views)

Does that mean that DLLs, .Net libraries and other dependencies should not be included within the library?
My logic for inclusion is that it makes it immediately obvious that they are a dependency with the hope of LabVIEW automatically including them when the PPL is used as part of a executable, for example.

 

I can't understand the decision behind making the paths absolute for things like this. I just makes it so unportable - everything that is non-LabVIEW must match exactly the same paths on the machine it is deployed to. It stores PPLs as relative so why not arbitrary files?

 

I'm going to build an empty DLL that has no other dependencies (apart from the typical core Windows ones) and see if that produces the same error (I suspect it will as it seems to be a LabVIEW design decision with absolute paths being stored).

 

Perhaps this is related to CAR 717261: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Application-build-destination-directory-should-not-re...



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
0 Kudos
Message 9 of 10
(171 Views)

I've now built a simple DLL containing a single function (add) with no other direct dependencies apart from kernel32.dll and MSVCRT.dll (verified using Dependencies) :

foo.dll direct dependenciesfoo.dll direct dependencies

 

As suspected, when directly referenced by the built PPL which has been moved - with relative paths between the DLL and PPL remaining the same - LabVIEW fails to find it:

Project viewProject viewFiles viewFiles view

 

Project files and DLL attached.



Using LV2018 32 bit

Highly recommended open source screen capture software (useful for bug reports).

https://getsharex.com/
Download All
0 Kudos
Message 10 of 10
(165 Views)