VI name collision using plugin type architecture

Question

I am using LabVIEW 8 and am building an application that will use a "plugin" architecture. There will be a main program built into an executable that calls sub vi's that are in llb's. Some vi's in the llb's will call DAQmx functions, others will do calculations, etc. Some math functions will be done in the main program too.
The problem I am trying to address is how to deal with vi.lib vi's that are used in the plugin llb vi's and the main program. For example, I use Mean.vi in one of the plugin vi's as well as in the main program. Where should Mean.vi be stored? A name collision occurs if it is in more than one location (i.e. in a plugin llb and the main program executable). This can get very complicated if many vi.lib vi's are used in the plugin llb's and the main program executable. How can I distribute vi.lib vi's that are required for my application to run? The application builder is fine for simple distributions but breaking up the application into several modules (llb's) that have functions (vi's) like a dll has some great advantages.
As side issue, does anyone know of a way to assign a version number of a llb file that is visible from its properties window in Windows?

Answer 1

TLE wrote:
I am using LabVIEW 8 and am building an application that will use a "plugin" architecture. There will be a main program built into an executable that calls sub vi's that are in llb's. Some vi's in the llb's will call DAQmx functions, others will do calculations, etc. Some math functions will be done in the main program too.
The problem I am trying to address is how to deal with vi.lib vi's that are used in the plugin llb vi's and the main program. For example, I use Mean.vi in one of the plugin vi's as well as in the main program. Where should Mean.vi be stored? A name collision occurs if it is in more than one location (i.e. in a plugin llb and the main program executable). This can get very complicated if many vi.lib vi's are used in the plugin llb's and the main program executable. How can I distribute vi.lib vi's that are required for my application to run? The application builder is fine for simple distributions but breaking up the application into several modules (llb's) that have functions (vi's) like a dll has some great advantages.
As side issue, does anyone know of a way to assign a version number of a llb file that is visible from its properties window in Windows?
I also use the plugin approach where a compiled .exe plugs in VIs which share vi.lib VIs with the main.exe. I did not yet use LV 8 for this, bit LV 7.0.
In principle there is no problem: the main.exe loads into memory first and with it the vi.lib VIs it contains (say e.g. mean.vi). When a plugin using mean.vi is loaded, it uses the instance of mean.vi which is in memory, i.e. the one which is stored in then main.exe (typically with its front panel and block diagram removed).
The problem starts when the plugin is closed, since the it asks if it should be saved to disk because the path to its subVI 'mean.vi' has changed. This is at least annoying. A workaround is to rename all VIs from vi.lib (and user.lib, instr.lib maybe) and save them to a different location before the .exe is built. That way all namespace collisions are avoided. I wrote a tool to do this renaming automatically. AFAIK there is a better (=more professional) tool for this purpose: the OpenG Builder, see at  http://www.openg.org/index.php?option=com_content&task=category&sectionid=4&id=68&Itemid=47. I haven't used it, though.
OTH: My understanding was that all these namespace problems have been resolved with LV 8 since its new application builder supported such autoimatic renamings. From your post I understand the problem is still there in LV8!? So one more reason not to upgrade yet. Maybe others can confirm.