How to ensure lvlibs and their VIs really end up inside the executable

[Mads]

I happen to have some JKI JSON calls, among other things, in a dynamically called plugin, and it seems that whatever I do in the application build specification to try to get all those support functions (members of lvlibs) included in the executable, the build insists on putting the support functions as separate files together with the plugin (the plugin is here a VI included in the same build, destined to be in a separate plugins folder).

(Sometimes I wonder if there is a race condition in the builder; what does it do for example if there are two plugins include din the build that will call the same VI, and the destination is set to Same as caller ..🤔That's not the case just now though, right now the only caller is one dynamically called external VI..)

In an ideal world I think I would create a destination for the lvlibs that plugins are to use in a single external support container-file like an llb...In the case of this JSON library though there are classes involved to, so an llb does not work (name collisions etc). Packed libraries are too cumbersome to use I think, for various reasons (having to support multiple targets for example).

So as a second best solution I want everything (all lvlibs that plugins may need something for) packed into the executable (works as a single file container, and supports classes as long as it is not using the 8.x file format...), but then the application build seems to behave very unpredictably. At first I would expect that if I included the lvlib on the always included list, and then set the destination of the lvlib to the executable I would be fine, but no. - Suspecting that this only applies to the lvlib-container file itself and not the VIs it owns, I then also set the destination for all dependencies and packed and shared libraries to the executable...- Still the builder puts lvlib-VIs together with the plugin. I have tried this with and without excluding unused members of the library with/without modification...and with and without disconnecting type definitions.

In the end I returned to the original build setup (as this was noticed after a conversion from 2018 to 2020), tried a build, got a Bad-VI error on a couple of VIs used by an xcontrol, set those to include the block diagram...and voila - magically this affected where the JSON lvlib ended up as well, even though they have no links in the code. This problem keeps popping up though, and once it is there it seems like getting the lvlib-files to the wanted destination always includes some voodoo...😧 Or does it?

Edited July 3, 2020 by Mads

[LogMAN]

4 hours ago, Mads said:

build insists on putting the support functions as separate files together with the plugin

You can specify a destination on the Source File Settings page of your build specification. The default is "Same as caller". I assume your plugin is set to a custom destination, but your support files aren't, so they are put in the same folder as the caller.

If you explicitly set the destination for your support files to the application executable, it will place them inside the executable.

Edited July 3, 2020 by LogMAN
Readability

[Mads]

6 hours ago, LogMAN said:

You can specify a destination on the Source File Settings page of your build specification. The default is "Same as caller". I assume your plugin is set to a custom destination, but your support files aren't, so they are put in the same folder as the caller.

If you explicitly set the destination for your support files to the application executable, it will place them inside the executable.

Sure, that's basic (always dangerous to say though, in case I have overlooked something else silly after all, it happens 😉).

The  lvlib and its content is set to always be included, and  the destination is set (on source file settings) to the executable.  The same goes for the general dependencies-group. The dynamically called caller of some of the lvlib  functions on the other hand is destined to a subdirectory outside the executable, and ends up there as it should. But then so does lots of the lvlib-stuff - seemingly disregarding that is destination is explicitly set to be the executable.

Correcting other usual suspects  (read: additional exclusions)  do not produce a repeatable solution either. Perhaps someone else here have observed similar voodoo though, and figured it out?

Edited July 3, 2020 by Mads

[LogMAN]

8 hours ago, Mads said:

But then so does lots of the lvlib-stuff - seemingly disregarding that is destination is explicitly set to be the executable.

I've never seen this kind of behavior. Only support files like documents, shared libraries and the like are supposed to be placed outside the executable, but I presume you mean VIs. This is very strange.

[PiDi]

I've seen this behaviour many times. We use OOP and lvlibs heavily in our projects and unfortunately often run into those builder quirks. The fun fact is that sometimes the same project built on different machines produces different outcomes (on one it always breaks, while on other it always succeed, while on third it's 50-50 chance). I never really bothered to investigate and report this to NI as those problems are very non-reproducible. Going to your specific question aboutt VIs which end up outside exe (in no particular order) :

1. Check the dependencies between libraries. The builder hates circular dependencies between them (i.e. something in lib A depends on something in lib B and vice versa). Avoid them - usually the solution is to move the offending VIs between those libraries. You'll also end up with better code design, so double the profit. 

2. Enable builder log generation (I think it's in Advanced settings) and see if you can make any sense of what it puts out regarding those "outside" VIs. 

3. Try building on different machine. 

4. Set "Enable debugging" for the build (also in Advanced settings I think). 

5. Try to recreate the problematic VIs under new names - create the blank VI, copy the contents (block diagram) of the current VI, replace the calls. Do not simply rename the current VI and do not Save as..., both of those might retain some hidden problems inside the VI. Also,try to change reentrancy settings and try to make them inline. 

6. Try to recreate callers of those problematic VIs in the same manner as above.

7. Separate compiled code from the VIs. 

8. On the contrary, do not separate the compiled code. Try to do both and see if there is any difference. 

9. Last resort - put the contents of the VI inside the caller. 

[Mads]

Good to see that we are not alone 😄

[Cusp Trap]

I was having a similar problem. The compiled EXE would always begin by asking me to browse for dependencies. The solution was to rename the main VI, i.e. move it to an unrestricted destination on my C drive. So I think the problem was caused by the main VI being saved inside the driver folder at C:\Program Files (x86)\National Instruments\LabVIEW 2018\instr.lib