LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Deploying Class Plugins vs VIPM

We've been having a little bit of trouble trying to work out a smooth workflow to enable our team of developers to extend some of our test applications.

To start with, we have a class that is the main API for our devices. This is getting deployed via VIPM so that our applications can be written to easily use our devices. This seems to work great - code the class, build a package in VIPM and all other developers get a pretty pallete showing the functions they need.

The challenge comes with this next part:

We wanted to create a test harness application that can be easily extended. This seem to be a perfect case for a plugin class / packed library architecture where the developers here could just create new test classes, build them to a packed library etc and then simply place them in a folder for the main test app to use. We know this concept can generally work great, but the problem we're having is that it seems to be incompatible with the API class we distribute.

Once the test interface class gets built into the top level packed library it "swallows" the API class and exposes it as a new name Test.lvlibp:API.lvclass instead of API.lvclass. This means that none of our pallete icons work (as those VIs belong to API.lvclass not Test.lvlib:API.lvclass).

We tried a work around of using an installer to deploy a packed library of the API class which solves half of the problem (in that the common API no longer gets swallowed and renamed) but we're stuck a little bit here on how to create the palettes etc (none of us have every deployed palette files and it doesnt seem very intuative on how to get them in the right place, linking to the right files etc). Also, unfortunately whilst VIPM appears to be the "sanctioned" way to deploy LabVIEW add ons now, it apparentely has no support for packed libraries (and no furture support planned).

Any ideas?!

0 Kudos
Message 1 of 5
(6,235 Views)

If you really want to use PPLs, you'll need to build the parent class (the one that ships in the EXE) into a PPL.  You'll then need to re-link the source of the plugins against the copy of the base class that is now inside the PPL.

Frankly, it's a non-trivial process.  I've become a fan of using source distributions for distribution of plugins - I wrote a blog on this very topic.  Maybe it'll be helpful: Recommendations for Deploying LabVIEW Plugins in the Run-Time Engine

Elijah Kerry
NI Director, Software Community
0 Kudos
Message 2 of 5
(4,279 Views)

Elijah_K wrote:

If you really want to use PPLs, you'll need to build the parent class (the one that ships in the EXE) into a PPL.  You'll then need to re-link the source of the plugins against the copy of the base class that is now inside the PPL.

Unfortunately, I see two problems with this approach. 

  1. This causes each plugin to be bloated with a copy of the parent class. 
  2. Each plugin may have a different version of the associated class, based on when the plugin was built

I need to read through your blog post, but my initial thoughts about source distributions is that they do not bundle everything up into one clean 'plugin' file which can be easily transported and loaded into a client's application.  This is the nice thing about PPLs

0 Kudos
Message 3 of 5
(4,279 Views)

1. Actually, it doesn't.  The parent PPL is not transported in the child's PPL.  The parent's PPL is transported and stored with the calling EXE.  Linking against a copy of the parent in a PPL is the only way to prevent the child from sucking it into it's PPL and re-qualifying the namespace.

2. See 1.  They'll all link against the same PPL that includes the base class.

Granted, you don't get one nice file on disk, but as you'll see in my post, you get one folder per plugin with all of the things that plugin needs flat within it - it's not terribly different from what a lot of other software vendors do with dependenceis that reside outside the  EXE.  Note that (as I do in my example) you can remove the block diagrams to prevent modificaiton of the output of a source distribution.

Elijah Kerry
NI Director, Software Community
0 Kudos
Message 4 of 5
(4,279 Views)

Yea, you're right. I misread your original post.  The problem we have is that we cannot distribute PPLs with our current workflow with VIPM (since VIPM doesn't care about PPLs and ignores them during an install).  That's our major problem.  So either we ditch VIPM and distribute PPLs using the standard NI installer, or figure out a new way to distribute PPLs

0 Kudos
Message 5 of 5
(4,279 Views)