LV2015 packed library calling DLL

[tstahl]

I've figured out what's going on, now just trying to figure out how to best solve it.

I'm migrating working code from LV2012 SP1 to LV2015 SP1. There are plugins using packed libraries. One of the plugins uses the OpenG compress library, so calls a DLL. This code works fine in source, but reports error 15, resource not found when call Get Default Value for the class. Recompiling with Enable Debugging checked produces error 1498, Library has errors, instead. I was able to investigate the code and found all of the OpenG compress VIs were the ones with the error. On a hunch, I added a couple of the VIs from the OpenG compression library to the VI loading the class in the packed library; the class loaded with no errors. I removed the OpenG VIs from the loaded VI and added the target build directory (containing the DLL OpenG compress needs) to my PATH environmental variable; the class loaded with no errors.

So, what this tells me is...

- LV2012 remaps the DLL location in the Call Library node correctly.

- LV2015 does not remap correctly

The executables and packed libraries I'm creating get built into installers (I'm using the one built into LabVIEW). I have a couple of thoughts on how I could solve this, but was wondering how others would approach this.

[AvatarAang]

Hi, tstahl! What was your solution for this issue?

A lot of the updates in LabVIEW 2015 had to do with optimization on the back end. It wouldn’t be surprising if LabVIEW 2015 would not include the library automatically in an effort to maximize efficiency when building executables.

Without seeing your code, I’m making some assumptions, but I’d take a look at these two ways to solve the error you’re getting:

• Call all VIs statically instead of dynamically
• Add the OpenG compress library into the “Always Included” box in the Source Files Category (Project Window > Tools > Build Application (EXE) from VI)

LabVIEW 2015 Features and Changes
https://zone.ni.com/reference/en-XX/help/371361M-01/lvupgrade/labview_features/

While this link does specifically call out the error you’re seeing, it’s not unheard of for one change to have impacts on other aspects ... I don’t know if this is something that was intended or not, but it looks like it may have affected the way your code is being mapped.

[tstahl]

allison.a -

Unfortunately my code is huge. The project schedule isn't going to allow me to parse it down to an example at the moment.

I see what you're referring to and that option is not checked, so turned off.

I think there is some confusion as to what is going on. The OpenG compress library is included in the packed library. The VIs that are in the compress library have a call library node inside. The call library node is broken in the packed library. By adding the DLL's path to the PATH environmental variable, the OS is able to locate the DLL. If I have the compress library in the main application, then the DLL is already in memory so doesn't need to be located.

My solution, at this time, is to put all of the DLLs my application and plugins need in an adjacent folder to my main application and add that directory to the PATH environmental variable. I'm using NI's installer, so I'll have to create an executable that runs after installation (there is an option to do so in the installer settings) to check if the path is in the environmental variable and add it if it is not. It appears setx is the Windows command that will allow me to do so (I really don't want to figure out how to elevate permissions with the Windows UAC).

[rolfk]

Actually if you add the DLLs to the executable directory you can avoid the addition of the special directory to the PATH variable. The executable directory is the first directory that Windows searches when trying to load a DLL that hasn't already been loaded and could not be found at the location of the full path of the library, if a full path was provided.

My guess is that earlier versions of LabVIEW added the DLL implicitedly to the packed library while the latest versions don't do that anymore since there is a potential compatibility problem if the same DLL with different versions is added in multiple packed libraries. Adding the DLL to the explicitedly always included section when building the packed library would help then, if this is the problem.