Why does Build Application vi work in development environment but not in executable; error 1025

[eye_in_the_sky]

Hello,

I have an application ("A") that I am trying to build using another application ("BuildA").

I can create an application for A manually from its project using the Build Specification, and it works fine (A.exe).

Also, when I run BuildA.vi in the development environment it calls the "Build.vi" correctly and again builds application A.exe just fine.

Then, when I make BuildA an application (manually) and run BuildA.exe, I would expect it to also create A.exe just like BuildA.vi did in the development environment.

However, it fails with the error:

Code: 1025

Open VI Reference in NI_App_Builder_API.lvlib:Build (path).vi->BuildA.vi<APPEND>
VI Path: <b>C:\TEMP\AppBuild\BuildA\vi.lib\AppBuilder\BuildTarget.vi</b>

I noticed this thread , which looks like a similar problem, but no conclusion was reached.

Why does BuildA.vi work fine in the LabVIEW environment, but the application BuildA.exe does not work?  All paths are hard-coded, so it shouldn't be a path issue.

Thanks,

-john

[Hooovahh]

Interesting code.  I'm curious how you came to decide 324ms in your while loop, and 58 in the other, and then 5136ms at the end.  In any case I suspect this has to do with this line of text in the help of the Build.vi.

If you plan to run a build specification on the LabVIEW Run-Time Engine, do not include the Build VI in any of the VIs for the build specification.

I don't fully know what this means but it might be why it isn't working.

The Build.vi opens all Context (application instances) and then looks for the one named "NI.LV.MxLvProvider".  This I assume is a application instance NI uses to build applications.  It then uses this and opens some other VIs in this instance for the building.  The error you are getting is "Application Reference is invalid" meaning it couldn't find the NI.LV.MxLvProvider instance it needs to build.  Again I believe this maybe because you are in a run-time environment and that instance doesn't exist there.

At the end of the day I'm guessing since Application Builder is not free, NI probably doesn't include it in the Run-Time engine, which is free.  So you can't build the way you want.  You could have and EXE running in the run-time open an instance in the development, then run your VI from there if you must make this an EXE.  It maybe easier to just edit the BuildA.vi to have a "Run When Opened" so that you double click the VI and it runs which behaves like an EXE sorta.

[rolfk]

The runtime engine only contains functionality to run precompiled applications. It does not contain any compiler, application builder or even a possibility to save a VI. This is partly for license reasons but also because the runtime engine is specifically meant to only run VIs and nothing more. Therefore NI removed all the functionality that does not have to do with running VIs in order to make the runtime engine substantially smaller than the development system.

[eye_in_the_sky]

Thanks for the quick responses.  First off, I just picked the timer delays "randomly" -- no special significance to those numbers.

As for the run-time behavior, what you say makes sense with regard to running on a machine with only a LabVIEW Run-time Engine and no full development environment.  But I was hoping it was possible to do it with the development environment present.

What we're looking to do in the final product is to incorporate an application that builds several LabVIEW applications (represented in the example by "A", but there will be 8 in all) into a script that does a lot of other functions as well (mainly building C++ applications, zipping and copying files, etc.). 

I was hoping to be able to add a line like

./BuildA

to the script, so it would launch the BuildA (the application that will build the other applications) in an automated manner, without the operator having to manually launch BuildA.

I guess we will have to keep the application building separate from the automated scripts  ... bummer

[Hooovahh · Accepted solution]

---

@eye_in_the_sky wrote:

I guess we will have to keep the application building separate from the automated scripts  ... bummer

---

There are still other options.  Lets say you setup the VI to run when opened.  If you ran the following command line from your script

"C:\Program Files\National Instruments\LabVIEW 2011\LabVIEW.exe" "C:\BuildA.vi"

Then it would open your BuildA.vi in LabVIEW and run it in the development environment.

[eye_in_the_sky]

Hoovahh wrote:

If you ran the following command line from your script

"C:\Program Files\National Instruments\LabVIEW 2011\LabVIEW.exe" "C:\BuildA.vi"

Good idea !  We are using MinGW to run Linux scripts in Windows as well as Linux in order to make them as platform independent as possible.  So I "translated" your command into the equivalent Linux command:

/C/Program\ Files\ \(x86\)/National\ Instruments/LabVIEW\ 2012/LabVIEW.exe BuildA.vi

... and it worked !  I had to make 3 mods to BuildA:

1 .. Removed the "Build" button and the while loop, so it would go right to the Build Application vi

2 .. Set Window Appearance property "Close afterwards if originally closed" to true

3 .. Added a call at the end to the "Exit LabVIEW" function so the window would disappear when complete

That did the trick - thanks!

-John