Get LabVIEW Class Default.vi cannot find the class in executable

[_Y_]

Architecture of my project includes dynamic loading of classes with Get LabVIEW Class Default.vi. It works fine under LabVIEW IDE. When compiled in EXE problems appear.

Get LabVIEW Class Default.vi cannot find the class specified in the class path unless the class was already loaded. The problem appears in parts of the code that are not new. They were already debugged and worked properly in EXE. Irrelevant parts of code were added; EXE was recompiled and the problem popped up.

I cannot upload the project here and I cannot reproduce the problem on a small scale.

The attached project doesn’t suffer from the same problem despite the solution is basically the same.

If the real project runs as EXE, the first frame generates error 7, the second and third frames work error-free.

Please suggest what could go wrong and how the problem can be nailed.

LabVIEW 2021 32-bit.

[Kyle97330]

I believe the only reliable way to use a dynamic load/plugin architecture is to use PPLs.  Create and build a parent PPL containing the parent class as Parent.lvlibp:Parent.lvclass, then create a child class inheriting from the parent in Parent.lvlibp (not the Parent.lvclass before it's built into a PPL).  Then put that child class into Child.lvlibp:Child.lvclass as another build, and load that to get the dynamic class load feature working.

I do not do this myself, but one of my co-workers does and it works for him.  I can't speak to a lot of details here because of that.

[avogadro5]

It seems like it should be working, I can't tell from your example where the problem is. But I have to ask why you're even bothering loading these things dynamically within an exe, rather than just statically linking?

[crossrulz]

The dynamic loading is likely the cause of the issue. If the builder does not see a hard dependency, it will not be included in the executable. By calling the class by path, the builder does not see the child as a hard dependency and therefore will not include it in the build. You can add the class to the "Always Include" in the build specification.

Personally, I go the PPL route Kyle was referring to. This makes the build for the executable a lot simpler/faster. If I find a bug in the child class, I only need to rebuild that PPL and my executable is still happy. If there is a bug in the executable, only the executable needs built, not the libraries it is using. It does take some care to keep the PPL build order and destinations correct. And then the deployment needs to keep relative paths between the PPLs. But after a few attempts, it becomes almost second nature. I also use the LabVIEW Solution Builder to build my PPLs.

[_Y_]

---

@Kyle97330 wrote:

I believe the only reliable way to use a dynamic load/plugin architecture is to use PPLs.

---

Yes, I developed projects where subclasses were dynamically loaded from PPLs. Such architecture works well but cannot be utilized in my current project.

Dividing code in several files (EXE + PPLs) is a more complex solution. I think, single EXE must work in the same way.

The single EXE architecture with dynamic class loading worked well for me in multiple instances for loading both: native classes and GOOP4 classes.

The story of the current project is strange. The compiled EXE had no problem. Its code has something like ten different factories where classes were loaded dynamically. Each factory loaded classes belonging to different class hierarchies.

I added one factory more. The problem popped up. And not only for the new factory. After the new compilation of EXE, one of the old well-working factories cannot find one (only one!) of the target classes. However, if the class is preloaded (as illustrated in my first post), the problem disappears.

Seems, something causes a compilation error. But what?

---

 wrote:

why you're even bothering loading these things dynamically within an exe, rather than just statically linking?

---

Dynamic loading reduces dependencies in the project. Low dependency projects have many advantages. These are some of these advantages that are important for me in the current project:

• Less loading time.
• Faster search in the code.
• Less number of automatic requests for recompiling.
• Easier identification of project dependencies.
• And, when running EXE, annoying delays are avoided.

[avogadro5]

Well error 7 is file not found. Try enabling build logging or do "get lv class path" to make sure the class is exactly where you expect within the exe. But obviously it's strange to find it the second time.

Another thing that may be happening is the app builder producing broken VIs. Try opening each method by path first and see if it's broken arrow, and be warned I've seen order matter where opening a VI unbreaks one opened earlier (for instance it may have a correct link to a file needed by both VIs but the 1st one has a broken link). This might be easier if you set the destination to the support folder then you can use file->open from the default menubar.

Another way to observe broken app builder output is to do a source distribution instead, I've had issues that carry over between exe and source distribution. You may be lucky and the distribution loads broken in the IDE, or you can build a bare RTE app and use the file->open trick to identify bad files.