Issue in calling a class and VI dynamically from exe

[தமிழ்நேரம்]

Hi Balaji,

               Please find the article that talks about the exact same issue.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAq8SAG

Also after removing the check boxes for all the subVIs shown in this VI hirarcy, I was able to launch the plugin and the class from the Exe.

[தமிழ்நேரம்]

Hi Balaji,
            Just for two subVIs(mean.vi and linearfit.vi) from VI.lib itself has so many dependencies. The best way to make any plugin to work is to create source distribution of the plugins, so that all the dependencies are automatically compiled and copied to the build location.
In the attached demo zip file observe the Application project file as well as the plugin project file for the build settings.

1) Both the build spec (from both project files) creates the build specification to the same build folder.
2) Both the spec refers to the LV-EXE-Root folder so that the dependencies from Vi.lib are automatically copied to this folder. Preserve hierarchy is enabled for this folder in plugins project after carefully moving all other dependencies to project.
3) In the additional exclusions page the Vi.lib is unchecked.
4)Also the exe is trying to load the plugin in the builds folder not from the source code folder.

[Mads]

I had the opposite problem now in one of my RT applications; A dynamic VI would only load when launched by the executable , not when the code in the executable makes the same call while executed from within the IDE (error 1003).

It seems this is because the dynamic VI calls a VI from NI_AAL_SigProc.lvlib, and when the VI is built into the llb it gets that dependency with it in the llb because nothing else is calling anything from NI_AAL_SigProc.lvlib.

Now when the main of the executable is run from the IDE and launches the dynamic VI, the dynamic VI expects the VIs it uses from the NI_AAL_SigProc.lvlib to be in an adopted form made during the build (local files included in the llb etc), but sees the original NI_AAL_SigProc.lvlib for some reason in memory, and this causes it to not load properly...

I still have not wrapped my head completely around this, but there is a good related discussion here:

https://forums.ni.com/t5/LabVIEW/Build-Specification-does-not-include-VI-which-is-part-of-a-quot/td-...

[Yamaeda]

This sounds a lot like an issue i ran into recently. It turned out that sometime LV (maybe in a service pack?) activated the Separate Compiled code on the Config file functions, and this compiled cash cannot be accessed in runtime.

I solved it by making a packed library of the function and this forced all required parts to be included.

(The other solution would be to untick it from all of vi.lib and remember to redo it on all development computers after reinstall ...)

/Y