.EXE with 3rd party add-on

[amcelroy]

Howdy,

 

I've written a program in Labview 2012 using a 3rd party add-on and would like to deploy it as an .exe.  The .exe seems to build (it even runs!) fine and includes a few custom .dlls written for the project, but the 3rd party add-on doesn't seem to have been added, either the library or the .dll.  

 

The project runs perfectly in the development environment.

 

Any hints as to how to overcome this problem?

 

Thanks,

Austin

[JackDunaway]

Austin: if the library is statically linked to your application, App Builder should suck in the library as a dependency during the build -- the LabVIEW API would be bundled into the EXE, and the statically linked DLLs referenced by the API would by default go into the support directory "data" next to the EXE. Perhaps, you're dynamically linking or lazy loading this API? If this is the case, consider marking the file as Always Included from the EXE build spec properties dialog.

[amcelroy]

Hey Jack,

 

Nice to speak with you again!  I added the library to the "Always Included" section and that did not work.  The build preview definitely doesn't show the add-on library or add-on dll in the Generate Preview pane.  As for the linking type, they are just being dragged/dropped from the front panel icons.

 

Thanks for the input,

Austin 

[ShaunR]

Whats the add-on? (Link?)

[amcelroy]

Hey ShaunR,

 

A little embarrassing, but my own

 

http://sine.ni.com/nips/cds/view/p/lang/en/nid/211893

 

Or the latest version at:

www.raptorview.net

 

Austin

[ShaunR]

Hey ShaunR,

 

A little embarrassing, but my own

 

http://sine.ni.com/nips/cds/view/p/lang/en/nid/211893

 

Or the latest version at:

www.raptorview.net

 

Austin

 

It looks like you are dynamically loading the dll with CL Test.vi (difficult to tell exactly because it's in evaluation therfore diagrams are locked and I cannot try a build).

 

Therefore LabVIEW dosn't know about the DLL. You will have to add the OpenCLV_xXX.dll directly as jack states (not the lvlib, which you may have thought jack meant by library)  and make sure it goes into the directory passed to CL Test.vi.

[amcelroy]

Hey ShaunR,

 

After adding the DLLs to the project manually and adding them as always include, the DLLs get added to the .exe under the data folder.  So one step closer.  The program still compiles and runs, but the behavior is the same, i.e. the program doesn't seem to recognize any OpenCL devices, though it does in the dev environment.  I've also tried move all the dlls to the same folder as the .exe, no luck there either.

 

My code that is deploying has the option to not pick an OpenCL device, which pops up an error that says no OpenCL device has been configured.  This error message is 100% from the add-on, so the add-on has been compiled and is in the .exe.

 

Fortunately the code is deploying to a dev environment where no .exe, but it would be interesting to know if other folks have had similar problems in the past. 

 

Austin

[ShaunR]

After adding the DLLs to the project manually and adding them as always include, the DLLs get added to the .exe under the data folder.

 

Is that where the VI that dynamically loads the DLL expects it to be?

[amcelroy]

Is that where the VI that dynamically loads the DLL expects it to be?

 

It expects the .dll to be in the same folder as the library (see picture).  Perhaps it has something to do with that?  The add-on is in the vi.lib virtual folder under Dependencies.  The error case displays a pop-up which says that there isn't an OpenCL.dll on the system, which isn't happening.

 

 

Austin

[ShaunR]

It expects the .dll to be in the same folder as the library (see picture). Perhaps it has something to do with that? The add-on is in the vi.lib virtual folder under Dependencies. The error case displays a pop-up which says that there isn't an OpenCL.dll on the system, which isn't happening.

Austin

Right. so that's a "no" then

In an exe,paths are different from development as the executable filename is included. Additionally, you placed the DLL in the data directory and there is no appending of the data directory in your path code.

To test, replace your path code in the image with an "Application Directory.vi", append the DLL name, and make sure the dll is in the same directory as the exe. This will ensure that when you build an exe, the dll is being picked up from the application directory regardless of how paths to VIs and libs mutate.

NB:

"Application Directory.vi" gives the path to the directory in which your project file resides when in the development environment.

Edited September 11, 2013 by ShaunR

[JackDunaway]

Agree on use of "Application Directory" (it looks like a primitive on the File Constants palette). I prefer to structure my dev environment file structure the same as the deployment file structure for scenarios like this; e.g., a folder called "Support" at the same level as the LVPROJ in the dev environment, which maps to the same relative directory as "Support" (or "data") sitting next to the EXE in the deployment environment.

 

However, in your case, since this the development of a COTS product; you may consider implications of statically linking this DLL rather than dynamically linking, so that App Builder takes care of the rest for your API end-users building EXEs. Since this toolkit is probably installed into vi.lib (rather than your project directory, i'm just guessing here), that's one minor level of complexity more than the method described above of straight mapping between dev/deployment environments.

[amcelroy]

Y'all are awesome!  That NI white paper was perfect.  Merged their solution for determining runtime, Shaun and Jacks's solution for Application Directory.vi for the runtime state and my previous solution for the dev environment state.

 

Thanks so much!