lvoop class error with built executable

[nileracecrew]

I am having trouble building an executable from a fairly large application in LabVIEW 2012.  The application runs fine in the development environment.  The project uses about 50 classes and several hundred sub-VIs.  I had some initial problems with build error 1502 (cannot save a bad VI without its block diagram), but after enabling debugging I am able to successfully build the EXE.  However, when I run it, a small dialog pops up before any front panels are opened:

LabVIEW: Generic File I/O Error.

The file "Hardware Detector.lvclass" could not be loaded.

After hitting OK, my splash screen opens up with a broken arrow, and another dialog reads

VI has an error of type E208.  The full development version of LabVIEW is required to fix the errors.

This is one of the classes used in the project. Based on advice I've seen other posts, I've tried a few things:

• Unchecking all boxes under Additional Exclusions (don't disconnect typedefs, don't remove extra files, don't disconnect inline subvis, ...)
• Adding the class folder to the Always Included list under source files (actually its grandparent folder)

None of these seemed to make a difference.  The only things I can think of that are unique about this class are that 1) it resides under a fairly deep folder hierarchy (five folders below root) and it makes use of the Set/Unset Busy Cursor VIs.  I don't know if any of that matters.

Any ideas?

[PackersFan]

I've struggled with very similar problems in the past and unfortunately, they were always a headache....

Are you dynamically loading this class?

If you go to the Source File Settings sections, what is the destination for this class?

Are you using the 8.x file layout?

You said you enabled debugging.  Can you connect to the EXE with a debugging session and check out the block diagrams?  Sometimes in my experience I found that those errors could be a bit misleading.

[Norbert_B]

Adding some questions:

Are all sources (classes and subVIs) implemented in the same LV version?

Did you masscompile the whole project before building the EXE? If so, did you get any "bad VI" reports?

Norbert

[nileracecrew]

---

@PackersFan wrote:

Are you dynamically loading this class?

If you go to the Source File Settings sections, what is the destination for this class?

Are you using the 8.x file layout?

You said you enabled debugging.  Can you connect to the EXE with a debugging session and check out the block diagrams?  Sometimes in my experience I found that those errors could be a bit misleading.

---

 By dynamic loading I assume you mean loading the class from a path instead of dropping a constant on the BD.  No, I am not.

Destination is the executable.

No 8.x layout

I can connect, but still get the same Generic File IO error.  Error list gives no errors.  I can open the splash screen block diagram, but once I started trying to open subVIs on the block diagram, LabVIEW crashed.  I might mess with this some more.

---

@Norbert_B wrote:

Adding some questions:

Are all sources (classes and subVIs) implemented in the same LV version?

Did you masscompile the whole project before building the EXE? If so, did you get any "bad VI" reports?

---

I initially started the project in LV2011, but migrated to LV2012 recently.  Never tried a build in 2011, but the class that seems to be creating the problem was written in 2012.

On your suggestion I tried a mass compile.  No bad VIs in the main code, but there were a few in a "test panels" folder in the project.  None of these VIs are called by the main code, but for good measure I removed the folder from project and re-built.  Same problem.

I did not realize application building was so fragile!  Thanks everyone for your help so far.

[GregFreeman]

Sorry to resurrect this, but if you're still around did you resolve it? I am having the same issue. This is happening with a class that opens VI references to a reentrant VI with a strictly typed refnum. I have always included, the VI, unhcecked the remove <whatever> check boxes, still no luck. 

[nileracecrew]

Fortunately I did resovle it, but unfortunately I don't know how.  At the time the application was under heavy development and that particular class was not critical yet so I removed it and moved on.  Later on I added the class back in, and it built fine.

If you haven't done it yet, enable debugging in the build options. It's been a while, but I think I still had to enable debugging for it to build.  I also went through multiple rounds of clearing the object cache and mass compiling, but that mostly seemed like waving chicken bones at it.

Sorry I don't have any concrete help.  

[GregFreeman]

I just made a new build spec just on a hunch...worked.

Slow clap for LabVIEW...

I still have the old build spec; I'll compare the XML later to see if something is corrupted.

[nileracecrew]

I'm almost sure I redid the build spec along the way too, so that may have fixed it for me as well.

I'd be curious to find out if you see any difference in the build spec XML.  When I was trying to solve this problem, I found other threads with similar weird behavior from Application Builder, but totally random apparent causes.  It would make more sense to me if it was a corrupted build spec, rather than Application Builder failing to build VIs with particular LabVIEW features.  Maybe not though.

Glad it worked out for you (for now).

[GregFreeman]

So, I renamed the build spec to the old build spec name -- failed again. Renamed it back to just "app.exe" and it worked. I wonder if it's a path length issue? Maybe the path length to the classes in the EXE is overflowing a buffer when it tries to load them (or something along those lines)

I'm going to try to reproduce in a smaller project when I have some time and send it to NI. 

[GregFreeman]

Followup:

I took a build that wasn't loading (gave me class errors that they couldn't be loaded), copied it to my desktop and ran it and it ran fine. Definitely a path length issue.