What are the limits of an llb library file

[dacad]

After much review and some experimentation of the different types of LV library files, I am planning on using multiple llb type libraries to contain groups of vi's for an extensive testing application (multiple deployments)

Driving reasons are:

1) based on info obtained in this forum, calling an item in an llb loads only that item while calling an item in an lvlibp packed library loads the entire package of files

2) appears source control will be simpler with an llb

3) vi's are compiled into a single container vs. just a list of files in a sub-folder like lvlib libraries so visibility (or lack thereof) and security are improved

4) by using the llb files, I can make mods to the system and have a much smaller executable to deploy and if I make a change to an item in an llb file, I don't have to recompile the entire executable

However, LV help doesn't explain very well what can and cannot go into an llb file.  In one instance, I was looking to contain all files associated with a particular pc of hardware since 1) it rarely changes, 2) it provides a single source for everything I need to interface with that hardware item wherever I need it.

I attempted to add a dll file and it appears I cannot do it.  Can I just drag files into the llb file manager or do I have to implicitly add them when saving from the specific vi or ctl file.  If that is so, I guess that guides me as to what files can be added to the llb, just ones you can open and save in LV.

Seems though, if you can include a dll in an executable, why not a library file.

Thanks for any thoughts on this, confirming or countering what I am seeing.

Doug

[Dennis_Knutson]

An llb was originally created to store files with long file names. This was in the days of the original DOS limitations. They are now considered obsolete except in a few cases for distribution. They do not lend themselves to source code control and a single corrupt VI in an llb will make the whole llb unreadable. Nor do they help with name space issues.

The VIs are not compiled into an llb. All VIs are compiled. There is a minor bit of compression in an llb. Security is actually descreased with the llb because of the corruption issue.

You cannot include a dll in an executable. I don't understand why you think you can.

[crossrulz]

You seem to have 1 major flaw in your understanding.  An llb is not code compiled like an EXE.  It is actually more like a zip file that contains VIs and controls (code and all).

1. Depends what you are trying to do.  Packed libries are fully compiled like a dll, ready to be called by an EXE.
2. I have found llbs to be more difficult on source control because you don't know which VI you changed.
3. They are not compiled.  The VIs are just contained in the llb.  It is not compiled like an EXE.  You will have to recompile your EXE.  Packed Project Libraries will allow you to not have to recompile your EXE.
4. Again, not compiled.

It is sounding like what you really want is the packed project library.

[dacad]

OK, so change compiled to packaged.  I understand that an llb is not a compiled file but rather a container that for my purposes, keeps the individual files from being end user accessible.

Wasn't sure about the ability of adding a dll file because, as I states above, the LV help does little to explain what can and cannot be included in an llb.

My reason for NOT wanting to use a packed library is that (and this IS in the help file) when you call on one item in the library file, everything contained in the packed library loads.

My ultimate goal is to be able to utilize small pcs of my application as needed based on part number of the units being tested.  Each part number has a specific test sequence. There are dozens and soon to be hundreds of different part numbers and I don't want to have all that load when I only need one at any given time.

For reference, if I build my entire application with all support and sub's today, I end up with an exe well over 20 meg and my IT doesn't give me rocket ship computers for production testing.

The core application will be the exe and I will call the code required for the part number dynamically. Once that code loads, it will stay loaded until the next part number and normally run from several hours to several days.

I had also considered OOP but that seems to be way overkill for what I am looking to do.  

Hope this makes my desired path a bit clearer.

Doug

[crossrulz]

I have to assume you are dynamically calling VIs then.  If you create a library for each part number, then you don't have your problem of tons of VIs loading.  Only the VIs that are needed will be loaded.  And once the main dynamically loaded VI is released, so will everything else in the library.  And they will be compiled like a dll.  The ultimate protection against somebody trying to muck around.

[dacad]

Yea but that means I have to manage those dozens to hundreds of files deployed to each system.  Another reason I want to 'package' them into a (or a few) container(s).

I maintain singular control of the contents (and respective rev's) of items in the container and then deploy the updated container as needed.