The future of Project Libraries: We need your feedback!

[Elijah_K]

Project libraries, *.lvlibs, were introduced in LabVIEW 8 to make it easy to create reusable libraries of code that could easily be shared and distributed.  They sought to make it easy to:

• avoid name conflicts (two instruments with an initialize function?)
• provide member VIs with access scope (public or private)
• create a default palette file to make it easy to pull them into LabVIEW
• create a single hierarchy of files

I've started this thread in the hopes of getting candid feedback regarding the use of Project Libraries for the sake of new feature development.  Are you using them?  What for?  What are the biggest challenges / complaints you have regarding Project Libraries?  We're listening!

[jgcode]

I really like project libraries and am trying to see how I can use them more in my (work) projects.

I like the ideas of:

- Providing access scope to a set of VIs

- Organising the layout of the project with virtual folders - so there can be one folder on disk (IMO easier for SCC so I don't have to move stuff around in subfolders) and a catagorised layout for the developer working from the Project Explorer.

- I can modularise development as the Project will link to the Library (just like Classes) and not the VIs directly.

- Renaming just the Library for distribution and not having to namespace VIs is neat.

- Now with the new build feature in 2009 there is no namespace clashes in EXE (same as Classes) which will make me want to use them more too.

One problem I just came across was:

I implemented a Queue-based API.

I decided to use Classes and pass the DVR (e.g. SEQ) around.

I made wrapper VIs for each public method and the Classes were designed to be private.

With the Classes in the library, trying to rename the Library caused LabVIEW (2009) to crash

This happened when making a distribution also.

In the end I had to take to Classes out of the Library so I could rename the Library for distribution.

I would have like to have had that Private Access Scope protection for the Classes tho.

I think I read something by AQ about Classes in Library problems?? - if the above worked it would be cool.

I am going to follow this thread as I am very interested to see how others are using it.

Cheers

JG

[shew82]

For what it's worth,here's my 2¢:

It seems to me that libraries and classes achieve the same basic goal (if you have VIs in a class that dont need the object wire, the implementation is pretty much identical).

I really like both of these - being able to control how a bunch of code is being used is one of the key things to build reliable software, and both classes and libraries allow you do achieve this goal.

I use libraries for two main reasons (excluding classes here for a second):

1. The first is namespacing, when we put together reusable components, it makes life so much easier if they are namespaced, especially when working with existing code - no need to worry about the same functionality already existing in that project.

2. TIdying up functional global type VIs. If I do need to create a functional global / action engine, rather than having a bunch of "recommended" inputs, I create the main FG as private and several public accessor methods with appropriate "required" inputs. This makes both me and other developers far less likely to wire up a VI incorrectly and really helps with encapsulation, as the implementation within those accessor VIs can easily change in the future.

One of the biggest things that I end up feeling very frustrated with regarding libraries and classes is that most of their properties are available only in the development environment. A really simple use case for how this can be frustrating is that there is no simple way to determine the version of a library or class being used by an application once it has been built into an executable (something that is very important for dynamically loaded class libraries, and would be really nice for statically linked regular libraries).

I have never had a lot of luck with the palette functions as you end up with a bunch of .mnu files in the EXE's data folder whenever you build an application, and creating MNU files is never as easy as one would want it to be.

One final thing that can prove challenging is that it is very easy for a library and it's contained VIs to end up separated. Whilst the separate files is useful for source control (esp. when VI files are binary), it does mean that libraries are considerably more delicate than their counter parts in other languages.

Shaun

[Elijah_K]

Thanks for the input JG,

Regarding the problem you had, I tried to reproduce the crash by renaming a Project Library containing a Class in LabVIEW 2009.  It worked for me, but as with any bug, if this is something that you can reproduce, please send the details to us at support@ni.com.

[jgcode]

Thanks heaps for the reply!

Here are some videos I took at the time. I just couldn't get it to work without removing the classes.

Do not rename Library – Build works

http://www.screencast.com/users/jgcode/folders/Jing/media/31437664-9d2d-4185-9e1d-059b379d1f4d#

Rename Library without Classes – Build works

http://www.screencast.com/users/jgcode/folders/Jing/media/76527136-4656-4a38-9949-13ed4d72c1a7#

Rename Library with Classes, rename Classes – LabVIEW crashes

http://www.screencast.com/users/jgcode/folders/Jing/media/9be1d507-2ef5-4f48-bc19-accd88b2353c#

Rename Library with Classes, do not rename Classes – LabVIEW crashes

http://www.screencast.com/users/jgcode/folders/Jing/media/c32f6f71-ce36-494a-ad16-1d2d46260a73#

[edit]

Yes, I can make a dist from a basic library containing a class, but so is probably worth mentioning the structure of the distribution.

The classes were each being sent to their own .llb file

All other files including the .lvlib, DVR wrapper methods, controls were being sent to their own .llb file as well.

Don't know if this contributed to it?

[/edit]

[Elijah_K]

Hey Shaun,

Thanks for the insights and the feedback.  As you've noticed, Classes are largely an extension of Project Libraries as far as how they are managed and displayed in the Project Explorer. 

To be clear, it sounds like you would like to be able to programmatically retrieve version information from a lvlib in a built application?  Also, do you know what it is you're doing with the VIs when they become separated from the Library?  Just moving them on disk?  How do you expect the library to behave?  Would it be valuable to package the contents of the Project Library into a single, monolithic file?

[shew82]

Yes, being able to programmatically retrieve version information (and other information that a user can input into the library file, such as documentation, etc) from the runtime engine would be very useful. The way we end up doing this right now is setting the version number in two places - once in the library and the second in a VI called "get version" (or something similar). This is far more important for classes than straight up project libraries, but is really useful whenever code is dynamically loaded (in my oppinion, at least ).

I have come across VIs that someone has moved (accidentally or intensionally) so that (a) the VI can no longer find its owning LVlib, or (b) the LVlib can no longer find one or more of its VIs. I think this is partly to do with the fact that when a VI is on a disk and being viewed outside of LabVIEW a user does not necessarily know whether its location is important.

I think the ability to package libraries would be beneficial (although LLBs fall very short of the mark here - they do not understand namespacing and cannot contain other files such as MNU or documentation) as a library could then become a contiguous entity, keeping the process clearer to a user of the library (ie they can put the library file wherever they like, it will contain everything it needs to know). In contrast, as it is right now, if a user wants to reuse a library the need to copy the whole folder hierarchy (lvlib, VIs, etc)  or else they end up with missing files that LabVIEW will then complain about.

I do see one major downfall with a single monolithic library file though: source control - As LabVIEW files are binary, it becomes very hard to establish what changed between versions (ie cannot see which functions / VI were actually changed, etc).

[Kennon_Cotton]

Shaun,

In LabVIEW 2009 you can get the Library Version via VI Server properties in the Run-Time Engine.  You can either get a reference to the lvlib with Application>Library.Open method or the new Application>Library.Get Ref By Qualified Name method if the .lvlib is in memory and then wire the reference to a property node and choose the Version property.  I just tried this in an EXE and it does work in 2009, but didn't previously.

Thanks for the othe Project Library feedback, keep it coming.

Kennon

[Jim_Kring]

KennonCotton wrote:

In LabVIEW 2009 you can get the Library Version via VI Server properties in the Run-Time Engine.  You can either get a reference to the lvlib with Application>Library.Open method or the new Application>Library.Get Ref By Qualified Name method if the .lvlib is in memory and then wire the reference to a property node and choose the Version property.  I just tried this in an EXE and it does work in 2009, but didn't previously.

Sweet!  Thanks for the update.

[Daklu]

I really like project libraries.  I especially like the way they keep the files organized in the project window.  I use lvlib's most frequently for thinly wrapping dll's, after which I'll wrap a class around the library to expose a higher level api to the dll.

Biggest issues:

• Doing a 3-way merge on .lvlib or .lvclass files is like walking through a minefield blindfolded.  If you're really lucky you'll make it to the other side intact.  If not, you'll spend a lot of time cleaning up the mess.
• Namespacing needs more flexibility.  Linking the namespace to the library file name is too limiting.  (I've had discussions with AQ about this in the past.  I think he understands where I'm coming from.)
• Loading the entire library when a single vi is used prevents me from using libraries more.  For example, I have ~a dozen utility error/boolean VIs that I've created.  95% of the time I use ErrorOrTrue, 3% of the time I use ErrorOrFalse, and 2% of the time I use one of the others.  I would like to put them in a library, but I can't justify dragging around all those unused VIs.  One or two libraries like that are manageable, but if you repeat that n times pretty soon you have a project that takes 6 minutes to load and 4 minutes to close.