Justin Goeres Posted September 5, 2007 Report Share Posted September 5, 2007 I'm having one of those this-has-to-be-my-fault,-right? moments. LabVIEW 8.5 is creating broken installers from the Installer Build Spec on my machine. See below. First I create an Installer Build Spec from an existing EXE (for what it's worth, the EXE builds fine). It looks like there's a graphical bug with the icons, but no big deal. http://forums.lavag.org/index.php?act=attach&type=post&id=6845 After I create the Build Spec, I click OK to return to the project window. When I reopen the Installer Build Spec the next time, the Source Files - Destination View has the WRONG FILES IN THE WRONG FOLDERS of the built application. http://forums.lavag.org/index.php?act=attach&type=post&id=6846 You might think this is just a graphical bug like I implied above, but you'd be wrong. The installer builds OK (or so it seems). I can even install the built software on a target machine without seeing any errors. However, when I try to run the software after installation, the application cannot find the constituent VIs it needs. http://forums.lavag.org/index.php?act=attach&type=post&id=6847 Furthermore, if I look in the installation directory on the disk, some class subfolders don't have the right files in them!. They have INI or CFG files (externally included to the project) or even other non-class VIs scattered throughout them, presumably in place of the VIs that should be there (that the application can't find on launch above). It seems that the problem is confined to class subfolders, although I haven't tested that rigorously. It should be noted that the project this is happening in is a few hundred VIs, maybe 15-20 LVOOP classes, and has a couple different app/installer build scripts in it. I managed to get one of the installer builds to work by doing weird voodoo like creating it from scratch and never viewing the Source Files pane after creating the build, etc. The exact same voodoo performed on this installer script didn't work. I can't imagine the Installer Build Spec is this completely FUBAR in LV85, but I'm quite sure my eyes aren't deceiving me. I have not tested this on another project file. Quote Link to comment
bpreis Posted September 5, 2007 Report Share Posted September 5, 2007 Hey Justin, That looks like a pretty major problem. Do you have some code you'd be willing to share - perhaps not the entire project but enough to reproduce what you've seen? Thanks. Quote Link to comment
Justin Goeres Posted September 5, 2007 Author Report Share Posted September 5, 2007 QUOTE(bpreis @ Sep 4 2007, 07:24 AM) That looks like a pretty major problem. Do you have some code you'd be willing to share - perhaps not the entire project but enough to reproduce what you've seen? Thanks. I'm currently pursuing a line of thought that involves making sure this isn't caused by the manual edits I did to the .lvproj file similar to these. I'm just loathe to believe LV85 could've possibly gotten out the door with the Installer Build Spec functionality completely b0rken, and the fact is that I was screwing around in the XML of the .lvproj... I'll post again when I know more. Quote Link to comment
Justin Goeres Posted September 5, 2007 Author Report Share Posted September 5, 2007 As part of my flailing on this problem, I decided to try to eliminate the possibility that my manual edits to the .lvproj XML were part of the problem. I started with a completely fresh EXE build spec, and a completely fresh Installer Build Spec. Without going into the hairy details of the app in question, I observed the following: The EXE Build Spec still builds the app correctly. The Installer Build Spec Source Files - Destination View window shows the constituent files from the EXE Build Spec correctly. (this is different from before) The actual Installer (Setup.exe, etc.) generated by the build spec still puts files in the wrong places on installation, and results in a broken application. But here's the interesting thing... The 2 files that the installed app (C:\Program Files\...) can't find appear to both be member VIs of classes that are part of a .lvlib file, and both have been replaced on disk by different non-VI support files that were manually included as part of the EXE Build Spec. I still can't be completely certain that my previous hand-editing of the XML isn't part of the problem, but the fact that I started by deleting the old EXE & Installer Build Specs (and verified they were gone from the .lvproj indicates against that. Note that if I manually take the missing VIs from the original EXE build output directory and place them in the correct folders of the installed application, the app launches fine. This isn't terribly surprising -- the compiled app is fine, but the Installer is just putting the wrong things in the wrong places. It's like it's somehow getting references to the wrong files when it's collecting pieces for the installer. Now if I could just bring myself to try to rig up a test project for this from scratch.... Quote Link to comment
bpreis Posted September 7, 2007 Report Share Posted September 7, 2007 So if I understand everything, You started with an exe build spec, which builds correctly. Your first pass through the installer builder lets you add files on the source files page, but the icons are all wrong in the project view, while the files all look correct on the destination view. After closing and reopening the build spec, the source file page has deteriorated further - icons are still messed up in the project view and the destination view now has completely wrong file information After all this, the installer builds fine and installs fine, but there are files the exe cannot find that happen to belong to classes (and an lvlib?) I'd agree those xml tags look wrong, like we somehow switched up the files when gathering information from the UI. Do you have a set of steps or files I could use to recreate the exe and installer build specs to reproduce the problem? Ideally, I'd like to make an exe, which hoses my installer builder source files page like what you've shown in the screenshots. I suspect it'll cascade into similar problems from that point on. Sounds like one key to this puzzle is to use classes and possibly an lvlib in the exe build spec. Let me know if you have more specifics on how to get into this state. Thanks. Quote Link to comment
Justin Goeres Posted September 7, 2007 Author Report Share Posted September 7, 2007 QUOTE(bpreis @ Sep 6 2007, 06:47 AM) So if I understand everything, You started with an exe build spec, which builds correctly. Your first pass through the installer builder lets you add files on the source files page, but the icons are all wrong in the project view, while the files all look correct on the destination view. After closing and reopening the build spec, the source file page has deteriorated further - icons are still messed up in the project view and the destination view now has completely wrong file information After all this, the installer builds fine and installs fine, but there are files the exe cannot find that happen to belong to classes (and an lvlib?) That's a very good summary of it, yes. I've done some more work and have managed to get LV85 to generate the incorrect information in the Installer Build Spec under a much simpler set of circumstances (starting from completely a blank slate in a brand new project). I'm not certain that this is a truly minimal set of conditions to trigger the bug, but it's got to be fairly close. Summary: LabVIEW 8.5 generates incorrect Installer Build Spec XML data under the following conditions: The project has two classes, one of which is the child of the other. The parent class has a Dynamic Dispatch method which is overridden in the child class. The EXE Build Spec contains a single dynamically loaded VI (manually added to the EXE includes list). In this example, this VI is not actually used by the Main.vi -- it's just manually included in the build. The project contains a .lvlib file with one VI in it. In this example, this .lvlib does not contain any of the files actually used in the EXE or Installer. It contains one VI which is not actually used in the project (it's just in the project file). NOTE: In this test, it was the addition of this .lvlib file which first caused the bug to manifest itself. Screenshots: 1. Project Window & Main VI http://forums.lavag.org/index.php?act=attach&type=post&id=6860 2. EXE Build Spec http://forums.lavag.org/index.php?act=attach&type=post&id=6861 3. Installer Build Spec (Note that this screnshot shows the first evidence of LabVIEW's confusion.) http://forums.lavag.org/index.php?act=attach&type=post&id=6862 If we look in the Installer Build Spec section of the .lvproj file we find that there's mismatched data in the FileInfo[2] properties, and that it matches what we saw in the Installer Build Spec screenshot above: 4. .lvproj Installer Build Spec XML http://forums.lavag.org/index.php?act=attach&type=post&id=6863 Now, the interesting thing is that in the configuration above, the EXE & Installer both build OK, and the Installer also puts all the right files in the right places. However, there's clearly a mistake in the .lvproj XML for the Installer Build Spec, and in my larger project the same kind of file substitution shown above causes the installer to subsitute some files in place of others, breaking the app. It looks like on a small scale, this may be a bug that doesn't have any consequences. In more complicated builds (like my original example) it's catastrophic. Attached to this post is a ZIP file containing the project described above. It also includes incremental archives of the .lvproj as I went along step-by-step. Please note that I actually started with an external supportfile.ini file as part of the project, and several additional member VIs in Class 1.lvclass. After the bug manifested, I removed those files to see if the bug would go away -- it didn't. I don't think those additions/removals are related to what I've seen, but I'd be remiss not to mention them . Example Project File: http://forums.lavag.org/index.php?act=attach&type=post&id=6864 To bpreis -- we can continue this discussion here in the thread, or we can take it offline if you prefer. It's OK with me either way. PM me with your outside email address if you want to take it outside. Thanks! Quote Link to comment
bpreis Posted September 12, 2007 Report Share Posted September 12, 2007 Justin, Sorry for the delay - got a lot on my plate atm . I downloaded your sample project and saw exactly the symptom you described. However, I noticed that when I delete the exe build spec from the Destination View of the Source Files page of the installer build spec, then re-add it, the tree information is re-populated correctly. It's only after I click OK (closing the build spec editor) and re-open the build spec when I see the bug appear. It's messed up in the same way on all subsequent loads. Another weird thing I noticed was that even though only one of the files appears to be incorrect in the UI, the XML seems to tell a different story - seems that both Write Numeric.vi files have the wrong FileTag I'm still investigating, but wanted to let you know I'm on the same page -B Quote Link to comment
Justin Goeres Posted September 12, 2007 Author Report Share Posted September 12, 2007 QUOTE(bpreis @ Sep 10 2007, 07:47 PM) I noticed that when I delete the exe build spec from the Destination View of the Source Files page of the installer build spec, then re-add it, the tree information is re-populated correctly.It's only after I click OK (closing the build spec editor) and re-open the build spec when I see the bug appear. It's messed up in the same way on all subsequent loads. Correct. I noticed that before, too, but left it out of my description because it wouldn't be apparent from the Project file I was attaching and would've complicated my description even more . Thanks for staying on this. Quote Link to comment
bpreis Posted October 4, 2007 Report Share Posted October 4, 2007 For reference, this has been documented in CAR 4E2BHO5U. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.