Leaderboard

Although this process is painful I am learning a tonne of new things about VirtualBox and InnoSetup. VirtualBox is a mighty impressive piece of software, I cannot believe I have not been making more use of it (especially snapshotting).

There are many things you'll find on at NI's website, which makes me think that at least some people there must be banging their heads running into these issues, so maybe there is hope. There's many ways to skin this one: I take the RTE distributed by NI, run the self-extracting EXE locally, then package up the result into my installer. At run-time I evaluate which (32 or 64 bit) to extract/execute and call the setup.exe with "/q /AcceptLicenses yes /r /disableNotificationCheck" (reference). I'll add my code for checking if the native version of the LV RTE is present: function IsLabVIEWMissing: Boolean;begin result := not RegKeyExists(HKLM, 'SOFTWARENational InstrumentsLabVIEW Run-Time13.0');end; Tests like this are evaluated in the Files and Run sections to determine if the appropriate item needs to be executed. Similar tests for .NET, MSVC.

If you are as impressed with Inno Setup as I am (couldn't live without it). you might consider a donation.

Edit: Yes. What Phillip said.

I think that these RTE Install options are still valid: Silent Installation of the LabVIEW Run-Time Engine

Just to (kind of) close the loop on this problem. I'll summarize what we found. A couple of weeks ago I removed about 20 (mostly abstract) classes from a library. I did this by: Adding all of our source code to a new project (in order to load everything into memory). Right clicking on the classes in question and selecting "remove from library" Our main VI continued to work afterwards, but the EXE started throwing a 1502 error. Changing the "Additional Exclusions" settings as described in this thread didn't help any: http://forums.ni.com/t5/LabVIEW/Error-while-creatiing-executable-Error-1502/td-p/669757 Anyone have any idea why removing classes from a library would cause the EXE, but not the VI to break?

Tom was able to track the problem down by painstakingly going through our source control and finding the point at which builds no longer worked. It turns out that it CAN be traced back to when we pulled the 20 abstract classes out of their library. We have no idea why this caused such an obscure and massively catastrophic set of errors from LabVIEW. Can anyone provide any insight on that? In the past, I've experienced some baffling and frustrating problems when pulling classes in or out of libraries. Nothing to this extent, but I'm wary of this operation (even moreso now!). Can anyone provide any insight as to why LabVIEW is so bad at handling what should be a simple organizational action? Additionally, is there any way to fix this without having to revert all our source code back to that point and "start over" with all our feature additions? It's over 2 weeks' of coding that we'd basically have to reimplement.

take a look at the VIs in vi.libutilityeditlvlibslvclass I believe that renaming the class also resets the mutation history.