Executable with Dynamic VIs

Question

LV 8.6.1f1
I'm having a hard time figuring out the ALWAYS INCLUDE field under the SOURCE FILES section of the BUILD properties in my BUILD SPECIFICATION.
My app uses "plug-ins".  You configure a channel (in my editor) as a plug-in channel, you give it a name "X".
The code looks for "X.vi" in a certain folder, runs it once to check out if it exists, figure out its prerequisites, and gets ready to run it for real. 
These plugins do things like compute a power channel from a speed and torque channel, or things involving chemistry.  Basically, they're fake channels, but the user can treat them just like real channels by adding alarms, graphing them live, etc.
These plugins use certain subVIs, and control typedefs (ENUMS, mostly) that are in the main program.
All this works fine in the development system.
If I build the app, my config puts the app alongside the main VI's library file, and the executable works just fine.
However, If I move the app (and the supporting folders with the plugins) to a different place (without the main source code present), I have trouble.
Specifically, when I make a channel ACTIVE (and thus try to dynamically load it), I sometimes get an error 1003, meaning the VI is not executable (broken).
When I flip the ACTIVE switch, I can see the LOADING dialog appear for just a tenth of a second or so. If I keep trying, I can eventually read the name of the VI it's looking for (some subVI, or control, used by the VI I'm loading).
If I modify the build spec to include that control in the project, it doesn't change anything.  I don't really expect it to, since the main VI already knows it needs this particular control (in a lot of places besides the plug-in).
However, if I add this control to the ALWAYS INCLUDE list, then things work just fine.
The question is: WHY?
I can guarantee that this control is in the EXE; it's used in a lot of places (including the editor that checks out the plugins).  I just did a search and found 807 instances of it. 
The help for ALWAYS INCLUDE says "Specifies the dynamic VIs and support files always to include in the application, even if the startup VIs do not contain references to the files".
I just confirmed that if i remove it from the ALWAYS INCLUDE list, it fails; if I add it back in, it succeeds.
Maybe it has to do with paths - in the development folder, I have :
Root\Main.llb\Main.vi                  { the main VI } 
Root\Libraries\Units.llb\Units.ctl   {the control in question }
Root\User\Plugins\Whatever.vi    {a plugin that uses it }
When I build the app, it goes into the root:
Root\Main.exe
and everything else is the same. 
I move the app into a testbed:
Root\Testbed\Main.exe    {the main program } 
Root\Testbed\User\Plugins\Whatever.vi   { a plugin }
and there's where the failure occurs.
So the questions are:
1... Why is this happening?
2... What rules do I need to follow so that it doesn't happen again?
I don't want to just dump stuff into the ALWAYS INCLUDE bucket until I understand what's what.
Ideas? 
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks
Solved!
Go to Solution.

Answer 1

The control is in the exe, but if you only have your plugin vi without the control, then the vi is not executable.
--- I don't understand what you're saying.  The control does exist in the EXE, it's used in lots of other places in the EXE.  So I was expecting the plugin to be able to find it. 
Every vi, you want to load dynamically, has to be executable independently from the exe which calls them.
--- That's not exactly true, specifically the "independently" part. 
More testing with lots of these plugins has yielded the following rules for my case:
The plugin itself does NOT have to be in the ALWAYS INCLUDE list.  That's obvious, or it wouldn't truly be a dynamic VI.
If the plugin uses a typedef control, then that control must be in the ALWAYS INCLUDE list.  It doesn't matter if it's used in the main already, even 800+ times.  It simply has to be in the list.
Any subVIs that the plugin calls have to either A) be already used in the main, so that they're in the EXE, or B) in  the ALWAYS INCLUDE list.
My confusion comes from the difference between 2 and 3.  Controls are fundamentally different from VIs in this treatment, and I didn't (don't) understand why. 
I said that your "independently" comment was not true because of #3.  These plugins are capable of finding subVIs in the parent EXE.  They're dependent on the EXE, but they can still work if that dependency is resolvable.  
For some reason, they're not capable of finding typedef controls in the parent. 
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks