LabVIEW
Works in IDE but not in exe
Here is another case of where the code runs in the IDE but not as an exe. Well OK, it does run in the exe in a lot of cases, however, in certain circumstances the exe crashes & disappears.
This is pulled out of a much larger project but left pretty much as-is.
The code is simple enough as see above (deliberately). Run the code from LV IDE with it pointed at one of your simpler vi from your GIT repository (or your Source Code Control [SCC] of choice). It probably reports as "GOOD". (I hope)
Now build into an exe and point it at the same vi and run it... Assuming you have followed good SCC practices, it should with pop up an error saying something about missing compiled code. Unfortunate for me, but reasonable after you think about it.
Now sift through your code and find a larger more complex file (larger than approx 150K) from your SCC repository and run it again. Observe how exe just disappears without warning.
It seems to be size related but probably related to the number of missing sub-vis (due to the missing complied code)
If you set the option to search for missing vis, you will sometime get a pop up error before exe disappears.
I hope I have describe it in enough detail and hopeful save someone many hours of debugging (like I just went through)
LV should probably be fixed to handle this case a bit more gracefully.
System info
LV 20.0.1f1 (32-bit)
Windows 10 Pro (Version: 21H2, OS build: 19044.1708)
SCC has little to do with this. SCC handles files, the VI uses files, but that's the only relationship. But, indeed, removing compiled code from VIs makes sense when using SCC.
The problem is most likely the compile cache. Or, rather, the missing compile cache.
I'm not sure, but is there any purpose in doing this in an exe? The exe state makes some sense (although a lot of code might be broken simply because it's not loaded in it's project or class). But the mods? If this didn't crash, will it work?
Search LabVIEW like a graph! 
It would be interesting to know where the crash happens.
If it happens on the Open VI Reference, none of your plans will work. And all's lost. Although you can check a connector pane without loading the VI (with Application>GetVI>ConPane ... methods).
@Frozen wrote:
1) It no longer works during development to debug your code
Why not? You mean debug an executable? I have no issues with debugging during development. Well, a few, but non related to separate compiled code.
@Mark_Yedinak wrote:
Why don't you look at using packed project libraries for your plugin architecture. Then you wouldn't have to do the checks on the VIs as you currently do. I have never been a fan of distributing source code to deployment machines. In addition, the PPLs will mean you have fewer actual files to distribute. This is very easy if your code structure is fairly flat without a deep hierarchy of PPLs. However, it is still doable.
I was under the impression that this exe would be a tool to help with SCC during development.
If you want plug ins, yes, use PPLs.
@JÞB wrote:
@billko wrote:
The thing that defeats all my possible scenarios is that this doesn't happen all the time...
That's exactly what has had me thinking about the use of Mods.vi. that property simply makes no sense in an application. Why would the flag exist inside an exe?
I am not following your train of thought. The exe is running with LV code as the input file, not another exe.
Exactly like you point out here:
@JÞB wrote:
But, I could see a use case to have an exe parse through source code so, it is simply a bad usage or the error being thrown should be thrown more often.
I would get rid of the suspect property nodes in the exe.
Unfortunately, it is the open reference that is causing the crash with missing compiled code, as seen in the original post.
My attempt to check for compiled code first (seen below) still causes the exe to crash/disappear ☹️
Guess I will have to put a note into the readme file about the potential crash using dev code. Not an optimum solution.
