LV2014 EXE loading vi's from disk with error "The VI is not executable"

[Thomas_robertson]

We have an EXE that has the ability to load our customers vi's from disk.  When editing the vi's in LabVIEW, they link to an llb that we distribute with our EXE, then when the EXE loads the vi it apparently relinks to vi's inside the executable (I believe, because we are able to update global variables in the EXE despite the fact that the vi's are linking to a global variable in the llb at edit time).

We recently made two changes that are causing a lot of problems with this scheme.  We have enabled "Seperate compiled code from source file" for all vi's in our program, and we have upgraded to LV 2014.  After rebuilding the llb and recompiling some example externally called vi's, the EXE fails to load the example vi's with the message "The VI is not executable".  After a bit of exploration I figured out that if I edit all vi's in the llb to turn off the "Seperate compiled code from source file" flag, almost all the vi's load properly by the EXE.  I was wondering if that's a known issue and if there's an explanation?  Is that something we will have to do from now on or is it a LV2014 bug?

There is still one example vi which is causing me trouble despite all subvi's having the "Seperate copmiled code from source file" flag off.  I have narrowed down the problem to an enum which is in one of the sub vi's it calls.  Even when I disconnect the enum from it's typedef and move it to the block diagram of the example vi and delete the call to the vi where it is used there is still a problem.  In other words, I have a vi which can be opened and run by the EXE and all I have to do is put this enum on it's block diagram which has a few entries and is disconected from a typedef and suddenly the EXE reports it as broken.  I am attaching the enum so that you can see it.    This strikes me as a LabVIEW bug?  Or is there something I'm not taking into account?

[Norbert_B]

First and most important:

Your "issue" with the LLB and the EXE is not only expected behavior, but intended.

That being said, you are obviously not aware that "Separate Compiled Code from Source File" is a setting you only use for DEVELOPMENT SOURCES.

Your LLBs are DEPLOYMENT SOURCES so this setting has to be disabled. Otherwise, the behavior you observe is the result.

As a workaround: You can build "Source Distributions" using the LV application builder to create LLBs with that separate option turned off. This is a nice workaround, as you should never mix development sources with deployment sources anyways!!

I am sorry, but your description of that enum thing is beyond my understanding. I just want to add in this context: Using (global) variables is most often a source for race conditions and leads to bad programming style and hence should be avoided. Esp. If you are using global variables within parts of an application which are later compiled into the EXE and the same global in parts which are going to be provided outside is imho close to a no-go for design. It is prone to lead to issues of any kind, most often these issues are sporadic, so hard to track, difficult to prove and costly to remove.

Norbert