Packed Project Library Pitfalls

[Jon_S.]

Packed Project Library Pitfalls

Intro

As a product support engineer for LabVIEW I became aware of some anecdotal evidence that our users were having a difficult time using PPLs.  I investigated all of our service requests and many forum posts that involved using PPLs. While there were a number of service request that were bugs or basic getting started questions, three main issues surfaced.  These three issues all centered around how PPLs pull in dependencies and live on disk. The root causes of the problems stem from a lack of understanding and/or using PPLs in ways that was outside of the development scope.  These issues aren’t necessarily bugs as the behavior is how we expect it to work. However, we do acknowledge that these are pain points that we have and will research how to improve.  Each of the three issues is summarized as well as a recommended solution for each of the problems.

Building Class Plugins Using PPLs

Classes have become the recommended way for customers to create a plugin architecture in LabVIEW. One feature that customers want to have is the ability to create plugins that are a single file.  This makes the application directory much cleaner and gives a more professional appearance.  If the plugin classes could be compiled into a PPL then the distribution would be wrapped up into one file.

Currently the recommended way to distribute a class plugin is to package the lvclass file along with the necessary VIs.  The user has to distribute the source compiled as a source distribution in order for the executable to load and use the plugins.  This user does have the ability to remove block diagrams for code protection but the individual files are still on disk.  Because of these issues, many users want to make PPLs the distributable plugins.

Several problems are encountered when trying to do this.  The main problems stem from the fact that libraries will namespace the files that are included in them.   Previously there wasn't a published way to accomplish the final goal.  One of our customers has come up with an architecture that allows users to distribute plugins that are contained within a PPL. For details on how to accomplish this please see this community document.  Many thanks to Michael Lacasse and his colleges at Lowell Observatory for posting this presentation.

PPLs Sharing Dependencies

Packed Project Libraries are built applications. Because of this all of the dependencies are pulled into the build, including any non-system dll.  This is the same process that happens when you build other build specifications such as shared libraries or executables.  In Windows an application can only load a DLL with the same name once and from only one location.  If LabVIEW.exe or a built application already has lvanlys.dll loaded into memory the user will get a load conflict warning when they load their PPL that also depends on its own copy of lvanlys.dll.  This isn’t a problem that is unique to PPLs though.  The same behavior would happen if you have LabVIEW built DLLs that depend on lvanlys.dll.  I am using the lvanlys.dll as an example because it is the most commonly used DLL that came up in my investigation.

The good news is there are ways to avoid this conflict.  The easiest way to avoid the problem is to add a prefix to all dependencies when you build the packed library.  This should ensure that the dll has a different name than the ones that ship with LabVIEW.  We actually do the same thing for our own builds that use lvanlys.dll.

If you are going to have multiple PPLs in a project you can make sure that you build them to the same directory.  If the prefix name is the same for all of the PPLs then they will share the common dependencies.  This will help keep the total number of items on disk and in memory to a minimum. Below is a picture showing a project that contains 3 PPLs that all depend on lvanlys.dll.  All of these PPLs are built to the same location so they will share the dll.  It was also prefixed so it doesn’t conflict with the lvanlys.dll that ships with LabVIEW.  See the example in the Share Dependencies ZIP file.

Nested Packed Libraries

Using nested PPLs has been an issues that has been discussed by our community before, in particular this article by Nancy Hollenback.  The main issue she addresses is having a lower level PPL that is called both by another PPL and the main application.  This causes multiple copies of the PPL to be on disk and possibly in memory.  This issue doesn’t have a great solution.  The one solution is to have the main VI call the lower level PPL that is located in the build directory of the top level PPL.  Because the lower level PPL is compiled and isn’t changed by the top level PPL during build it will function the same.  This makes iterating or changing the lower level PPL a challenge but it is the only way to keep one PPL of each type on disk.  An example of this is included in the Nested Libraries ZIP file.

Jon Soneson - LabVIEW R&D Staff Software Engineer (formerly LabVIEW Product Support Engineer)

[CoastalMaineBird]

This issue doesn’t have a great solution.

No kidding.

I'm wrestling with this now, with the situation where Main calls PPL "A", and PPL "B", but PPL "B" could also call PPL "A".

The trouble with the just-call-the-copy-of-A-that-is-alongside-PPL-B approach, is that, in my situation, PPL "B" is a plugin, and thus completely optional.

[AristosQueue (NI)]

If PPL A is already in memory when you load B, the one in memory will be used instead of loading new from disk. If it is not in memory, then B will load A from the one sitting next to it. That should work for you.