Plugin architecture with shared dependencies

[DerrickB]

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.

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.

[crossrulz]

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

[DerrickB]

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.

[Vijay_J]

---

@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.

[DerrickB]

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!