LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Plugin architecture with shared dependencies

I've developed a framework that is comprised of several libraries and handles tons of UI, logging, graphing, etc. There is a compiled executable that these libraries get compiled into. I have a plugin that I'm compiling into a packed library (lvlibp) that also depends on these libraries.

 

LoadPackedLibrary.png

 

Some of these libraries include functional globals that store configuration loaded between the main exe and all plugins. However I've read that compiling into a packed library also namespaces all dependencies which is causing my main exe to not see that the plugin has been loaded even though the plugin's initialization ran without error. Is there anyway around this namespacing done by the packed library so that the functional globals that the plugin sees are the same as the main exe?

 

I've also tried doing just a source code distribution for the plugin but it doesn't use the dependencies compiled into the main exe when I try and load it. The source for the framework libraries needs to be in place in order to open the initialization VI for the plugin. With this solution the main exe's functional globals are used to store the plugin's configuration at least and it can see that it has loaded, though I'd rather not have to distribute the full source of the framework alongside what's compiled into the exe.

 

In both situations I've ensured the framework gets compiled into the exe by putting all of the libraries in the "Always Included" section of the build specs. For the plugin, I let it leave any dependencies it can out of the packed library.

0 Kudos
Message 1 of 5
(1,432 Views)

Make another PPL that contains all of your FGVs.  Then make sure all of your code is referencing that PPL.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 5
(1,419 Views)

Alright then, with hundreds of VIs in these libraries referred to by the main app, is there an easy way to change dependencies over to the packed library? At that point I'd rather just distribute the source as there are already several applications in the field that would have to have all of their dependencies switched over to the packed library.

 

I'm also not liking what I'm seeing as far as what VIs are exposed with having to choose a top level library. All of the libraries in the framework are "Top Level" and it's not looking like I can get access to them properly.

0 Kudos
Message 3 of 5
(1,411 Views)

@DerrickB wrote:

Alright then, with hundreds of VIs in these libraries referred to by the main app, is there an easy way to change dependencies over to the packed library? At that point I'd rather just distribute the source as there are already several applications in the field that would have to have all of their dependencies switched over to the packed library.

 

I'm also not liking what I'm seeing as far as what VIs are exposed with having to choose a top level library. All of the libraries in the framework are "Top Level" and it's not looking like I can get access to them properly.


Make a copy of those libraries used by the main application and plugin.

 

Create the PPL of each library in a copy made.

 

Add these PPL to a folder (which is not part of the project file of the existing application as well as the plugin)

 

Later you can right click the libraries in the existing project and simply replace them with PPL's, which will replace all the callers with the VI’s from library to PPL.

 

Hope this helps.

Message 4 of 5
(1,371 Views)

I've never noticed that replace with a packed library option, not that I was ever looking for it. Some day I'll go ahead and give this a shot. I've got a work flow down for deploying llb plugins so I'll stick with that for the time being.

 

Thanks!

0 Kudos
Message 5 of 5
(1,344 Views)