LLB's

[ErnieH]

It seems nowadays that using LLB's is no longer widely accepted and considered by many to be obsolete. I have used them for transferring files, re-linking files in one place, storing my globals , etc. NI uses llb's extensively to distribute there code. The only down side I know of is that if corrupted, all files are corrupted (I personally have never seen one corrupted in 17 years) Of course you can have backups and can save to a directory if desired. I have had less problems with these than with libraries personally. If they have been obsolete all these years, why are they still widely used by NI?

[Darren]

As a developer in LabVIEW R&D at NI, my development with LLBs is fairly limited at this point.  Many of our existing APIs and other support VIs in the LabVIEW distribution were originally stored as LLBs, and it hasn't been a priority to move them into folders.  The only new LLBs I create are for the VI Analyzer Toolkit, which currently requires that tests be stored as LLBs. 

If we ignore the special case of the VI Analyzer Toolkit, though, the new APIs and support libraries that I have added to LabVIEW over the past several years have been in folders (and most of those folders contain a .lvlib to further organize the VIs).  At this point, the SCC limitations of LLBs (in that they must be stored in the source control depot as a single file) are the main reason I no longer use them.

[crossrulz]

My only use for an llb is for polymorphic VIs.  That way I keep all of the VIs together in a single file and I don't accidentally forget one when moving it to another machine.

[yenknip]

The last time I used LLBs was a couple of years ago when I was lumping together a bunch of plug-in VIs. Partly for the same reason as crossrules; so I didn't forget a VI, and also to disguise the files as a dll.

[Freelance_LV]

Our current guidelines expect us to save all our project files (vis, controls, menus, etc) in a library. This is the first time I am using LLB in my 4 years of LabVIEW work.

If I have to use the file from one project in another project (because it meets most of the functionality), I will have to first copy the file to the new project folder, disconnect it from the previous project's library and then reconnect it with the current library.

Oh! Today I copied and converted almost 15 files!

Is there a better way around?

[SteveChandler]

I really like llb's in that you only have one file to distribute as others have mentioned. I don't like that they are called libraries but due to legacy they will always be called that. If llb's had all the functionality of lvlib's they would rock! Loading one large file is much faster than loading a bunch of little files. Packed Project Libraries are not ideal because they don't include the source, yada, yada.

I hope nobody minds me pimping another one of my ideas but I would really like a hybrid between lvlib's and lvlibp's.  http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Bundled-Project-Library/idi-p/1564800

Before anyone mentions problems with source control remember that this is just a distribution tool and not intended to be something you actually develop code in. (I have seen people regret developing code in llb's) This "Bundled Project Library" would finally make llb's unnecessary except for where they are required by existing API's.

[JW-JnJ]

Like crossrulz, I only use them for packing polymorphics together.

Besides the usual arguments, I have a new one: they don't play very well with subversion conflicts. The LabVIEW Merge and Compare utilities do not work with llb's. As soon as you get a conflict, you're manually resolving each VI. However, I have been lucky and haven't had this happen, so haven't looked deeply into it. There may be an easy way I'm missing.

It always feels funny to me adding VI's from a LLB to a LvLib. Feels like redundant redundancy.

[Mark_Yedinak]

I would replace any use of LLBs with packed libraries. You get all the benefits of a single file to distribute yet your code is not subject to a single corrupted VI taking out your whole library. I highly recommend looking into packed libraries if you haven't already.

[SteveChandler]

That's a good idea, but keep in mind that using a ppl means that it will only work on the platform and version which it was compiled for. An llb can be recompiled. The idea which I shamelessly pimped above would solve that.