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: 

Building multiple EXE's with common code

I’m trying to determine the best way to use Application Builder to deploy a fairly large LabVIEW project to computers which do not have a LabVIEW development system installed.  This project consists of:

 

  • Multiple top-level VI’s, each of which should be compiled to a separate executables.
  • Multiple plug-in classes which are dynamically loaded by the top-level VI’s.
  • Common modules (LabVIEW classes, project libraries, and individual VI’s) shared by both the top-level VI’s and the plug-in classes.

 

Everything works well under the development system, and also when I use a single build specification to both build the EXE for one top-level VI and to place the plug-in classes in the correct folder relative to the EXE.  However, this seems wasteful, as it makes a full copy of all of the plug-in classes, and their dependencies for each top level EXE.

 

If I try to build the EXE with one build specification, and a source distribution for the plug-in classes with another build specification, error 1448 occurs when I load some of the plug-in classes using “Get LV Class Default Value.vi”.  I suspect that this is due to having the same common VI expected at two different paths (i.e. one embedded in the EXE and a second copy in the folder where the plug-in class is located).

 

Is there any way to use multiple build specifications to build several EXE’s and a “library” of common code in such a way that everything links properly?

 

Mark Moss

Electrical Validation Engineer

GHSP

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

It is possible, but I will save you the trouble - if it works as a monolithic executable, leave it at that. It may be wasteful, but computers are powerful, memory is cheap and headaches resulting from trying to manage dependencies aren't.

 

If you want, you can find some plugin schemes in the large apps group over at the communities area of this site, but you're probably better off not going into it if you don't actually need the functionality.


___________________
Try to take over the world!
Message 2 of 3
(2,363 Views)

Thanks for the pointer to the large apps group.  I was able to use the instructions at https://decibel.ni.com/content/docs/DOC-19176 to use packed libraries to encapsulate my plug-in classes.  It was a fair amount of work, but modifying the plug-in system to work with "monolithic" VI's probably would have been as much or more work...

 

Mark Moss

Electrical Validation Engineer

GHSP

 

 

0 Kudos
Message 3 of 3
(2,329 Views)