Make LVLIBs work (hassle-free) in executables

[SteenSchmidt]

LVLIBs are great for a number of things, but they can become a pain when used in a built plugin-architecture (exe + source distribution with plugins). I propose a couple of the worst pitfalls gets ironed out by improving the build script and process:

1) When an LVLIB includes a public polymorphic VI, which member functions also resides in the LVLIB but are private, a build including this LVLIB breaks with (a somewhat weird) error code 1502 (Cannot save a bad VI without its block diagram) if "Remove unused polymorphic VI instances" has been checked in the build script.

The build failure is ok, but error code 1502 makes this case hard to debug. The reason for the failure is of course that you configure the build to remove the poly-VI, leaving the instance in its place. But the instance is in private scope thus rendering the calling VI broken during the build process. I propose the "Remove unused polymorphic VI instances" setting only removes the poly-VI when this will not break the code.

2) When both an executable and a source distribution (from which your exe calls a dynamic VI) use the same LVLIB, you risk ending up with a broken dynamic VI at runtime if "Remove unused members of project libraries" is checked in either of the build scripts. This is due to the fact that the LVLIB will only go into memory once (when the exe loads), and the source distribution will then be forced to use this copy of the LVLIB. If the exe build removed instances from the LVLIB that the dynamic VI should've used, the dynamic VI will be broken at runtime. Also quite hard to debug. The solution is to configure the LVLIB as "Always Included" in both build scripts, but this is error-prone. Instead I propose either to split the "Remove unused members of project libraries" setting up into a separate setting for each library type, or maybe have a new page in the build script letting you configure this setting for each of the LVLIBs in this specific build (automatically identified from inclusions and dependencies). Anybody can chime in here with their preferred solution.

Cheers,

Steen

NB. I must add that suggesting just to disable those two options in the build script isn't a good solution. That usually results in a very lengthy build process and a huge exe/source distribution.

[SteenSchmidt]

Arghh, I have just found a new failure mode that is unfortunate: If a poly-VI is a dependency of a VI inside an LVLIB, that poly-VI always gets replaced with its instance during a build if "Remove unused polymorphic instances" is checked, even if the poly-VI is set as Always Included as well! This could be a bug in the app builder?

Details:

- I explicitly add "..\vi.lib\GPower\" as an autopopulating folder to my LV projects (so I'm able to Always Include the toolsets I need in the build specifications, to avoid their LVLIBs being carved out by the app builder).

- I have two build specifications in the project in question; one exe and one source distrib. Both Always Include the GPower folder from vi.lib.

- GPError.lvlib contains a poly-VI (FilterCodes.vi) and its two instance-VIs (FilterSingle.vi and FilterMulti.vi).

- A function in VIRegister.lvlib uses FilterCodes.vi (the FilterMulti.vi instance).

A) Upon building the exe the FilterCodes Poly-VI gets replaced with the FilterMulti instance-VI within the VIRegister.lvlib function, and the poly-VI is stripped from GPError.lvlib as well.

B) Both VIRegister.lvlib and GPError.lvlib are left intact within the source distribution.

C) When the exe calls code within the source distribution, the crippled GPError.lvlib is accessed breaking the source distrib code = not as specified in the build specifications.

/Steen

[Thoric]

Glad I'm not the only one who suffers from these frustrations. Kudos.

[^N]

I am having this issue now with my current project. I have an lvlib which contains a bunch of plugin classes that are called via dynamic dispatch. These are all being removed at build time.

I agree with:

---

@SteenSchmidt wrote:

have a new page in the build script letting you configure this setting for each of the LVLIBs in this specific build (automatically identified from inclusions and dependencies).

---

So as far as I can see there are three options:

1) Uncheck "remove unused members of project libraries" for the build to work (which inreases my application size from 6mb to 18mb)

2) Add each class to the block diagram somewhere so that it is referenced - which is something that is bound to be forgotten with multiple developers working on the plugin classes and negates the point of having a plugin in the first place.

3) Build the library into a PPL - which I think is what I'm going to go with, though which I don't really want to do.

[AristosQueue (NI)]

Steen: The bug, really, is that polymorphic VIs and the instance VIs should be required to have the same access scope, but we cannot fix that without breaking user code at this point.

^N: In your case, the behavior of the AppBuilder should be that if the classes are in your project (i.e. NOT in the Dependencies section but actually listed in the project) then they get built into the app even if not directly referenced in any other way so long as the parent class is used by your app. Or, to phrase it another way, "IF parent class is used in a VI being built into an app THEN all child classes of that parent that are listed directly in the project will be included in the build, even if Remove Unused Files is checked." The reason is that the children are considered to be used if a dyn disp VI could dispatch to them. If they are only in your Dependencies section of the project, they don't get included because we assume you want those as dynamic dependencies outside the EXE.

If this is not the behavior you are seeing, open a support ticket with an application engineer to investigate. To the best of my knowledge, this has been the policy since the beginning of LV classes and I know of nothing that would have changed it in recent versions.