LabVIEW
[BUG] Application Builder fails if the target window is open
See the multiple reports at http://forums.ni.com/t5/LabVIEW/Getting-Vague-Build-Error-When-Making-Executable/m-p/3196611
Could LabVIEW please make the build process succeed even if the target folder is open?
Or if that's too hard, could LabVIEW please do a check at the start of the build process, and pop up a helpful message telling the user to close the window? (rather than reach the end of the build and then fail with a cryptic message, "Error 6 occurred at Invoke Node in AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Bu
(A CAR would be much appreciated! *hint hint* 😉 )
The check in the beginning won't help to much really. Most times when I run into this error it is because I'm to quick to try to look at the resulting executable rather than that the Explorer Window is already open at the start of the build process. (Disclosure: I'm pretty quick to close windows on my computer, often without even noticing, only to wonder a few minutes later where it has gone!)
I'm having a real hard time isolating it too. Attached are two build logs when one fails and one works. I write a simple project that involved the lvinput.dll and an itextsharp.dll, but it isn't reproducible enough yet, if I get some time I'll play with it some more.
Man I am so confused, I've tried in 2014 and 2015 and I've gotten about 3 or 4 different failure conditions so I'm not convinced this is from the same build issue. Some times I get Error 1 which appears to be something with this thread. But in 2015 I've also seen a new one which I hope is related.
The icon at C:\Program Files (x86)\National Instruments\LabVIEW 2015\appLibs\lvapp.ico could not be written to the application. Verify the icon is at the expected location. If using the default icon, please contact National Instruments technical support with this information.
C:\Program Files (x86)\National Instruments\LabVIEW 2015\appLibs\lvapp.ico
Click the link below to visit the Application Builder support page. Use the following information as a reference:
Error 1 occurred at AB_Engine_EXE_Call_Write_Icons.vi -> AB_EXE.lvclass:Build.vi
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
And another one seems to isolate it, but not sure if reproducable. I was looking in the builds folder and it failed (attached) then I moved out of that folder and built again and it passed. Attached is the 2015 project I used, steps are pretty much do a build, then explore, then do a build, if it didn't fail go into the data folder then build, if it didn't fail come out of the build folder then build, if it didn't fail open a new explorer window and repeat, I never made it far before it would fail to build for one reason or another.
@fi$h_Tank wrote:
Hi all,
I am trying to reproduce your issue so that I can file a CAR. I have built an executable five times in a row with the target folder open and it has successfully built. I have not received an error at all. What version of LabVIEW are your running, and will you please post screenshots of your process so I can make sure I am reproducing your issue correctly. Thanks in advance for your time and effort!
Perhaps my assessment of the problem's trigger (and thus the thread title) is inaccurate.
I've encountered this issue every so often, across LabVIEW 2012, 2013, 2014 (all 32-bit), and across Windows 7/8.1. After a few encounters with this issue, I worked out a reliable way to make it go away every time it rears its ugly head: Click "Back" in Windows Explorer to back out of the target folder, delete the existing target folder, and try rebuilding. From experience, the next build will then succeed. I never bothered to investigate further to find the root cause.
Then, when I saw the discussion at http://forums.ni.com/t5/LabVIEW/Getting-Vague-Build-Error-When-Making-Executable/m-p/319661 , I thought the trigger had finally been identified, and that the issue was reproducible by many. That's why I started this thread (but I didn't try to reproduce the issue before posting).
Annoyingly, I'm now unable to reproduce the issue at all on my machine, whether in LV 2012, 2013, or 2014... 😞
@Hooovahh wrote:
Man I am so confused, I've tried in 2014 and 2015 and I've gotten about 3 or 4 different failure conditions so I'm not convinced this is from the same build issue. Some times I get Error 1 which appears to be something with this thread. But in 2015 I've also seen a new one which I hope is related.
The icon at C:\Program Files (x86)\National Instruments\LabVIEW 2015\appLibs\lvapp.ico could not be written to the application. Verify the icon is at the expected location. If using the default icon, please contact National Instruments technical support with this information.
C:\Program Files (x86)\National Instruments\LabVIEW 2015\appLibs\lvapp.ico
Click the link below to visit the Application Builder support page. Use the following information as a reference:
Error 1 occurred at AB_Engine_EXE_Call_Write_Icons.vi -> AB_EXE.lvclass:Build.vi
Thanks for putting time into this, Hooovahh.
I've never seen the icon message before, but I haven't used LV 2015 yet either.
Judging from the reports we have so far (i.e. the issue is not always reproducible, and the failures don't always look the same), I'm guessing there's a race condition or two in the build process: It works fine often enough, but when the stars align, it stops working. If this is the case, then there are no fixed steps to reproduce the issue reliably... (Fi$h_Tank: Is there a policy on opening CARs if there's a race condition that prevents reliable reproduction?)
For me the error happens pretty reliably when I go and open the folder in Explorer while LabVIEW is building an executable. I see the various files appear then the executable library is build and at the point where the application builder tries to combine the VI library with the executable stub to create the final executable file it errors out with a pretty uninformative long error message about error 8 (not sure about the erorr number really the error dialog isn't exactly formatted in a way that makes it interesting to really look at it and not just click it away annoyed) or something and the build has failed. If I remember to close the Explorer Window before it reaches the stage of creating the final executable image it usually goes fine.
Currently I don't get it very much anymore since I remember to wait for the Application Builder to tell me it has finished its magic, before going to the build folder in Explorer. Also I'm predominantly working across various versions of LabVIEW so there is a chance that newer versions exhibit a different behaviour/error code here but I just haven't encountered it anymore since I try to avoid the entire issue completely anyhow. One additional maybe unimportant tidbid: My explorer windows are almost always set to display in Details mode, pretty icons are quite unimportant during development, informations like last modification and such on the other hand is quite useful.
Another tidbid: While one suspect might be virus scanners that can't really be the only cause since I have worked in the past quite extensively without an always active scanner in the background (and never had a virus or troyan on the system then). Even nowadays the only things the virus scanner does is slowing down the computer and incidently report the unavoidable "dangerous" internet tracking cookie every now and then.
So in general another thing I noticed is, if a build failed all that was needed to make it work again was to delete the build folder, or some times just the contents of the build folder. Maybe we could just make a Pre-build VI that deletes, or backs up and renames the build folder. Oh or better yet get in the habbit of using that new function (2014?) that puts the build version in the folder name, that way in most cases the build folder won't exist at the start of the build.
Still if this is a bug it should be investigated, but I don't think NI wants to take this on without more examples of it yet.
