Allow VeriStand custom devices to be built as lvlibp instead of llb

[CyGa]

Hi,

LLBs are outdated, suffer from name collision because it doesn't embedded lvlib nor classes, and force the VIs to match the exact same LV dev version with VS runtime version (to be able to run the compiled code of raw VIs on the target without the need to recompile them).

It would be preferable if custom devices/controls could be built into lvlibp instead.

It has many advantages such as:

* Source protection

* Respect of lvlib and lvclass namespace (avoid name collision)

* Only the compiled code is stored so they are smaller than LLBs

* Compiled code made with LV 2017+ is compliant with upper versions of the run time engine (would allow keeping the version of LabVIEW while upgrading Veristand)

I'm pretty sure the limitation nowadays only relies on file extension filtering to find the 'main' VI to launch in the SysExplo and engine. If I'm right the change could be done easily.

[iwane]

Actually, Veristand will happily run a Custom Device that is built as lvlibp. System Explorer will display a warning, but the code will run fine - tried it.

Kudo given anyway - it would be nice if it was official...

[CyGa]

Hi Piotr,

I've got to test it then!

If it works well, then it can be a real game changer! 

And yes, this should be official !!

[Darin_G]

Starting with VeriStand 2021 R2, we officially support building Custom Devices into PPLs. Using a PPL-based custom device can help improve deployment times with a smaller disk footprint, avoid load-time conflicts, and avoid internal naming conflicts.

The Custom Device Developer Handbook now has instructions on how to migrate a LLB CD to a PPL-based CD. In addition, the VeriStand Custom Device Wizard now supports generating a PPL-based CD when using the inline and inline-async HW templates.

NI Guidance: The vast majority of existing Custom Devices should not be converted unless they are hitting an issue that PPLs would fix, but any new Custom Device development should leverage PPLs.