Built classes directly into an exe for dynamic loading. But now the installer builder claims that the files can't be found in the built exe?

[Mike_Le]

Here's the situation:

I'm dynamically loading lots of classes in my application. These classes are sent to known destinations inside the exe, as specified in the exe build profile.

The exe builds and runs flawlessly.

But when I try to create an installer for the built exe, I get an error claiming that the files can't be found.

It looks like this:

---

The following file(s) are not found on the system:

C:\builds\APT\APT.exe\Dialogs\Configuration Manager\Configuration Manager.lvclass
C:\builds\APT\APT.exe\Dialogs\Configuration Manager\Configuration Manager.lvlib
C:\builds\APT\APT.exe\Dialogs\Configuration Manager\Read All Modules Ready.vi
C:\builds\APT\APT.exe\Dialogs\Configuration Manager\Read Caller Data SEQ.vi
C:\builds\APT\APT.exe\Dialogs\Configuration Manager\Read Dialog Launched.vi
C:\builds\APT\APT.exe\Dialogs\Configuration Manager\Read Element of Enqueuer Array.vi
C:\builds\APT\APT.exe\Dialogs\Configuration Manager\Read Elements of Enqueuer Array.vi

etc...

Ensure the files exist and any included build specifications are built.

That's no good!

When I hit "Show details" on the error window, it returns the following:

---

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 7 occurred at CDK_Utility_GenerateErrorCluster.vi -> CDK_Engine_FileExists.vi

Possible reason(s):

LabVIEW:  File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.

=========================

NI-488:  Nonexistent GPIB interface.

Looking at the installer profile shows that it thinks the classes should be in a FOLDER called "APT.exe" rather than actually contained inside the file "APT.exe." This is bizarre, as the exe build profile makes the correct distinction and knows that APT.exe is a file, not a folder. I'm able to set destinations to be within APT.exe and the files build into the executable, rather than a system folder with the same name.

I'm new to using dynamic class loading in applications; is this a common issue? What's the solution/workaround?

Thanks guys.

[mikeporter]

Does the executable that you created work?

Mike...

[Mike_Le]

Yes, as I said, "the exe builds and runs flawlessly."

That means the exe builds with all the classes embedded inside. There is no extra "APT.exe" folder; all the files are actually embedded in the APT.exe file. The program executes as expected with all functionality. When I close the exe, the task is removed from task manager and doesn't linger.

[mikeporter]

Hmmm... That's what I was afraid of.

The installer builder is known for these sorts of strange things -- you mentioned that there are several classes involved. It looks like it is related to one particular class try removing it from the build and see if the installer works or just complains about something else.

[Mike_Le]

It complains not just about one class, but about EVERY class that's loaded dynamically. When loading classes dynamically in a built exe, you have to specify their locations inside the build profile. This is what's done under "Destinations." Specifically for classes, they must ALL be either inside or outside the exe.

Because my application is deployed to end-users, I want the classes opaque to them, so I set the destinations to be within the exe. This works fine, and the exe builds without problems, with all the classes embedded inside.

The problem is the installer thinks all the classes that have been built into APT.exe are actually located in a system folder called "APT.exe." That's obviously wrong, so when it tries to grab those classes from a nonexistent file location, it returns an error.

I know I'm not the only one building classes into exes, so I can't be the only one seeing this problem.

[mikeporter]

I have done this myself and not had any problem. How exactly do you have the class destinations defined in the build?

Mike...

[Mike_Le]

I posted a picture of my destinations here. Hopefully there's something trivial wrong with the way I defined them that you could point out?

[majoris]

I seem to be trying to do something similar if not exactly the same. I have child classes only called via the LV Class Default By Name vi and the converted to a parent class via the to more specific class VI.

When I hit this chain of calls in the project, it works fine as all the vis are in the project. Specifically, the entire class hierarchy is in a specific project folder. However, when I build the project into an executable, only those VIs explicitly called on the block diagram are included "in memory". So when the lvclass name pops out of the default value vi, I get an error 1373 that says the class could not be loaded. When I look for the VIs in memory from the application reference, I don't see them.

In the project, I add the folder with all the classes to the Always Include folder. Under Source File Settings, they are listed as always included. I tried forcing the destination as the executable with no difference.

I unchecked all exclusions to be sure none of them were excluding the classes. In the build script, the classes listed under Source Files as expected. If I look at the Application Property Libraries in Application Instance, I see my classes in Labview but not in the executable.

So, besides putting them on the block diagram, how do I make sure they end up loaded by the executable? Thanks.

[crossrulz]

What you need to do is use relative paths for finding your class that you will load.  Using the Current VI Path and Build Path will do it.  Your relative paths from a VI will not change from project to executable.

[majoris]

I'll try that out but this help document made me think I needed another way to trick the class into memory: http://zone.ni.com/reference/en-XX/help/371361K-01/glang/get_lv_class_by_name/