Drawback of packed library vs old llb

[dacad]

In configuring my app to be deployed to multiple systems, I will be creating the exe that contains the core code and all support vi's. Then there is the group of vi's where each vi is an alternate test method.  I will be editing/updating/adding test methods in an ongoing basis.  There will be dozens if not a few hundred before it's all over with.  These I want to be able to deploy to the various systems in a quick and efficient manner in real time.

There are two aspects of this I am working to finalize. 1) how to call the required vi (either with dynamic calls or LVOOP)  and 2) how to 'package' the vi's for deployment.  Number 2 is what I need some input on here.

I have determined the potential options are, in no particular order, llb file,  dll file,  lvlib file,   lvlibp file.

llb pulls all the vi's into a single file and manages calls to them.

dll appears to have idiosyncrasies that I don't want/need to deal with.

lvlib appears to be essentially just an organizational file and acts pretty much like a project file, even opening in a regular project window and does nothing to 'contain' the group of vi's it points to.

lvlibp does what the lvlib does bit it does pull in all the vi's into a single file pretty much like the llb file does and opening it is the same as opening an llb file.

From the research I have done, it has been indicated that the llb file is old school and becoming obsolete though in reality, it will be around for many years to come because many, many third parties will continue to supply their support tools in llb files.

If take that to heart however, that would leave the lvlibp file. Seems a good choice but when I read about it in the lv help, I got this little blip that made me screech to a halt.

"Include only related VIs in a packed library. When you open a VI in a packed library, all VIs in the packed library load. If you include non-related VIs, load time increases because more VIs need more time to load."

As indicated initially, I will have a large number of vi's to deal with, easily reaching several hundred meg in size.  I don't want to add that much overhead just to use one little piece of the pie.

So now, my questions are:

Does an llb file exhibit the same behavior when a contained vi is called? (that being, do all the vi's load into memory?)

Is there some method I have not discovered yet that will allow me to deploy a dynamic group of support files to multiple systems in a simple and concise manner?

Any thoughts on this are as always, appreciated.

Doug

[Joseph_Loo]

Have you thought about the following scenario:

    1.  Multiple users

    2.  Different versions or types of Labview

    3.  Source control.

If an of the above occurrs, it will force a new version of the libraries. If your project gets large, it beomes quit significant and difficult to isolate the changes that occur. I have gone back to single file for each vi and make sure the source does not include the compile code.

[dacad]

This is for deployment on multiple in-house systems all running same version of LV.  Each system will have the same compiled exe.  If it happens to get updated, it will be deployed across the board.

Users are a non-issue here. They are operators that follow the prompts.

Source control options are beyond the scope as everything is pushed in this environment. End users see only an icon and instructions.

If I maintain the individual vi's on each system, it creates the liklihood that something will get missed.  I want to have a single location for current version code, top level and plug-ins, to manage.  I expect to have to recreate the library (or whatever I end up with) quite often as, especially in the beginning when new products are added to the automated systems, I will be adding new test vi's a couple times per week.

I don't think I have an issue with the overall plan of controlling the deployment of the updated vi's, just the physical format that they will be in.

Doug

[Joseph_Loo]

Spoiler

I create an installer and place all the compiled files into the exe file. Yes, it is larger, but it allows you to check the exe file it contains everything. I do this with dynamic calls to vis which can be messy.

My bad call. I did not realize you were in deployment mode. Generally, I usse llb only for development and do not deploy then as separate items for executables. Creating a single exe via the project builds ensures that none of the libraries do not get out of sync when you install the program.

[crossrulz]

What I did for a system was use Tortiose SVN as my source control.  Then I had all of the similar systems networked together so they could look at the same repository.  Saved me weeks of trying to figure out what code was the latest, what VIs are different on each system, etc.  Source code control is your friend, even in this deployment stage.

[Joseph_Loo]

I use git for my source control. But I broke them up as separate files and make sure that the Vis are separate from the source. This allows me to do development between windows and linux. Otherwise the compile code will trigger updates when the code is compiled.

[Mark_Yedinak]

If you use LVOOP you can define your class hiearchy such that you can build the base class into the exe. Use packed libraries to package the children classes. This should reduce some of the size issues you have if your base class can contain a fair amount of common code. The nice things about a plugin architecture is that it is easy to extend your test cases by simply deploying new plugins. You do not need to rebuild your application. If you deploy everything in a single exe then you need to rebuild and distribute new version to extend your application.

[dacad]

I appreciate the input but I really think you guys are answering questions that are different than what I asked.

My deployment will place two packages on my assorted test systems. 

Package One will be the built Exe and what few support files it needs that I need to keep independent.

Package Two will be all the various test methods (dozens and likely a few hundred eventually).

This, I thought, automatically implies a plug-in architecture.  Whether I use dynamic calls or LVOOP, it is still set up so I can update Package Two without disrupting Package One.

My task is to decide what to physically use for Package Two.

Package Two can be:

from one extreme, a folder full of vi's (Good - Loads only the target vi into memory,  Bad - Poor method of controlling proper versions and lots of files to move around,  Ugly - It's just plain messy)

to the other extreme, a packed project library or lvlibp file (Good - A single file to deploy, Bad - A call to a single vi loads the entire library into memory, Ugly - Well, no real ugly I guess)

The in between that I am trying to find more information on the older llb format.  I don't have a problem in the world using this if it allows a single vi to load without loading the entire library.  So far, I have not been able to determine how it acts when called upon.  I may have to actually build a small scale example with multiple methods of packaging the plug-in vi's and monitor memory while running them.  This will be a bit tedious as I have limited access to one of the target machines right now.

If anyone knows the ins and outs of using llb files, or can point me to a location (NI or other) that will let me research, I need your assistance.

Then, if anyone knows of a LV technique that allows me to package a group of files and then let me call on one without loading all the rest into memory then  I need your assistance as well.

Again, I appreciate the other feedback but it's not really giving me what I need to go forward intelligently

Doug

[Mark_Yedinak]

I think you may not be understanding what I am saying. I am not recommening that you place all of your tests into a single packed library but rather treat each test as as it's own packed library. To distribute new tests you simply add the packed libraries to the directory with your plugins. this allows you to version each test, not the set as a whole. If you use LVOOP ach test becomes a child class.

[dacad]

I got that but that puts me back in the situation where I have a huge number of items to maintain on the deployed systems.  Whether they are source vi's or individual packed libraries, a hundred test cases equals a hundred files, regardless of their format.

That is what I am trying to avoid.

Doug