Platform: LabVIEW 2015, Windows 10
Project containg multiple targets: PC, cFP-2220, cRIO-9030 and sbRIO-9651.
I kept getting errors, mostly "Error -1 occurred at CDK_Utility_GenerateErrorCluster.vi -> IB_Source_Container.lvclass:Report_Preview_Error.vi"
when trying to build an installer the other day, and the troubleshooting gave me some insights that I think might be useful for others (and might get NI to do some changes too perhaps):
Building the application that was going *into* the installer worked fine....so why on earth was the installer build complaining? (At first I also had some manifest errors and was sent into a long blind-alley deleting MDF-folders and repairing LabVIEW (I am not sure if this was really related to the same issue or not)...but even after that I would get this Error -1.) At first I did not take it serious enough that the error came with a "Possible reason: Error generating preview for xxx application". Why should I - The application was budiling without any errors(!). And if I opened the code under the PC target which I was buidling for there were no warnings or changes to be made...
Well, as it turns out the issue here was that because the project contained multiple targets, some with RT support, some not and in such cases whenever you start working on a target that has different conditional disable symbols involved, you have to load the VIs with conditional
disable structures to get them to actually update for that target - and I had missed *one* dynamically called VI that had such a conditional structure!.
This is where the application builder now seems to have become semi-smart though (making the issue with the installer much harder to figure out); Even though there was one VI that had an unresolved issue /recompilation of a conditional structure outstanding - the application build resolves this automatically; the build completes without errors. HOWEVER - when the installer build script is running it does not just use the already build application - it tries to generate a Preview of that application build - and the Preview generation is not as "smart" as the application build itself - it fails. - So, this behind the scenes (and not intuitively necessary) part of the installer build causes the installer build to fail due to the application build - even though the application build succeeds(!).
Thanks for sharing you findings.
The VI that had an unresolved issue, was that one included in the buildt exe or was it a dependency added to the installer alone?
Did you get it to build properly?
The VI with the unresolved issue was included in the app-build. Not just in the installer.
Once I discovered that the installer build was more sensitive to the application-files than the app-build (due to relying on the app build preview instead of just the full app build) it was only a matter of finding and opening the affected VI and saving it again.
I ended up posting this as a product suggestion on the idea exchange. The preview function is primarily built to be quick; to work as a preview for the human user - not be as smart as the app build...However, when used in the background by the installer build that priority is less logical. Then it should be as robust as the logic of the app build itself.
Thank you for posting on Idea Exchange. It is a good way of getting suggestions on R&D's radar.