Best practice for plug-in building?

[Dan Press]

This one has my wheels spinning a bit. I think it is because I am thinking of too many different ways to accomplish something, and I just want some opinions on what is best.

I have an application that supervises an inspection process. The application reads the results of the various inspections and logs them to a database. The customer has requested multiple charts and graphs to present statistics based on database queries. Since the customer keeps dreaming up different views and P-charts, Pareto Charts, etc. I would like to make each chart type into a plug-in and deploy them to the customer as a single file (ZIP or LLB perhaps) that they can drop into a designated folder. The application would then list the contents of that folder and make the plug-in available through a menu.

Where I get stuck is on the build / packaging of the plug in. I want to make use of some subVIs that are already in the main application, but I know that I will need to include those subVIs that are only in the hierarchy of the plug-in as well. So what is the "best practice" for packaging my plug in such that it includes what it needs and excludes what is already going to be in memory as part of the main application?

I see my options so far as the following.

1. Who cares about duplicate subVIs? Just make a Source Distribution to an LLB from the Project and let it throw everything in there. If the subVI is already in memory, it should just use that, right?
2. I care about duplicate subVIs! I can make the Source Distribution, but I can painstakingly exclude all the subVIs that are already part of the main executable. The operative syllable being "pain".
3. Perhaps I can beat the OpenG Builder into some horribly disfigured mess that will do what I want.
4. I could create a tool to do this while feeling like someone already did this. Did they?
5. There is NO.... number 5. Or maybe there is.

Thoughts?

- Dan

[Antoine Chalons]

I've been thinking about that too.. and never really knew what was the best thing to do so I went for option 1.

One comment though, I've made many plugins for Vision Builder AI (different version from 2.5 to 3.6) and when building the plugin's llb every VI in the hierarchy goes into it, some VIs are renamed and some not.. I've never really tried to understand how and why, it could be interesting .-o

[Daklu]

3. Perhaps I can beat the OpenG Builder into some horribly disfigured mess that will do what I want.

I can't respond to 'best practices' as I haven't done a complex plugin architecture, but I have used OGB a lot. If I'm understanding you correctly, you don't have to beat OGB into submission to get it to do your build. (You might have to beat your dev process a bit though...) The problem with OGB is that the 'Exclusions' tab takes precedence over the 'Source VIs' tab. Any VIs you attempt to include on 'Source VIs' that are in the directory tree of a folder you have chosen to exclude will not be included in the build. To solve the problem make sure the directory where you develop your plugins is outside of the directory trees of any of the main sub VIs your plugins use. Then you can simply exclude the directories that contain the sub VIs you are reusing.

There are a couple things I can suggest trying:

• Develop your plugins against distributed code instead of your source code. In other words, install the main application on your dev computer and link to those sub VIs instead of the sub VIs in your development directory. This is what I would do. Your source code tree is likely (and should be) in a completely different location than the install location, making excluding all the reused sub VIs a one step operation. (Exclude the installation directory.)
• You implied there are lots of sub VIs you are reusing. If the majority of them are not in a parent directory of your Plugins directory you can exclude them by excluding those directories. Then you could go through and individually exclude the few remaining reused VIs that exist in parent directories.

[Edit - This addresses how to build your plugins in a way to avoid including the reused sub vis. I'll leave the packaging to someone else.]

Edited July 27, 2009 by Daklu

[John Lokanis]

I do something like this, but in my case I *do not* want to have the plugin share sub-vis with the main app, even if they are really the same VI. This is because I may have 'upgraded' that sub-vi after releasing the main app and broken backward compatibility. So, I use OpenG builder to build my plugin LLB and namespace all the VIs so they never share with the main app. The only exceptions to this would be functional globals that I want the main app and the plugin to share. In that case there is a tab in the OpenG builder to exclude a VI from the LLB (forcing the plugin to use the one in memory from the main app).

I find the easiest way to build something like this is to have a project with all my plugin code in it and one VI that is never run, but has all the VIs needed by the plugin on it's BD (top level VIs and any dynamic VIs). I call this the 'static links' vi. This is the only VI I include in the OpenG builder setup. By doing this, it picks up all the required VIs and puts them into the LLB.

Beware including or not including the vi.lib VIs in your LLB. If you don't then you will have to hope the main app included the ones you need. If you do, you will add to the overhead of your LLB and will need to include any external DLLs those VIs use (a good example for me was using Fieldpoint VIs in my plugins but not in my main app, leading to many un-fun build issues/bugs).

OpenG Builder is a great tool for solving your problem. I wish NI had some of this functionality natively.

-John

[Abdullah R]

I usually build my exe and have it call plugin VI out of "Support" folder that sits next to the exe file. The exe calls the plugin VI out of that folder using CallByRef node. The only catch is that you need to have plugin VI hierarchy in that folder or else it will give error saying subVI is not executable. My plugin VIs following certain naming like plugin_Foo1.vi, plugin_Foo2.vi etc etc. So depending on plugin VIs found in "Support" folder, the exe shows the user available plugins as "Foo1" and "Foo2".

Good thing about this model is that, you can update and throw new plugins into "Support" folder without updating your exe. Exe or Source Distro build specs are little tricky but else it works out very well. It is much better than having all the dyn plugin VIs packed into one fatty exe that takes seconds to load. By doing this you also get benefit of on demand loading.