LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Need a Way to Reverse-Replace Packed Project Library with LabVIEW Library

Status: Completed

Available in LabVIEW 2019 and later. You can right-click a .lvlibp in the project and select 'Replace With...' to replace it with an .lvlib, and vice-versa.

This idea is about a new LabVIEW feature, the Packed Project Library.


To statically use a packed library as a dependency, you need to add the library to the LabVIEW project.  After that's done, all the callers link to the packed library.  If you're strictly a library user, then whenever you need a library update you simply ask the developer for one.


But what happens if you're a packed library user and developer of the same library.  You can't use a packed library as a static dependency until you build it and replace the lvlib with the lvlibp...but you can't develop the packed library after it's been built and replaced in the project.


If you're a user and developer, it makes sense (to me) to maintain two separate projects.  One manages the packed library resource, one manages the application.


What if there were a way to revert the packed library to the LabVIEW library from the same project?  You could use the spiral development model and simply switch between the two types of libraries during development.  You could also (and this IMHO is the most important part) incrementally deploy and test the project.  If you're strictly a packed library developer, hopefully you're incrementally testing anyway.


My final pain point with the packed library is with respect to upgrading the application.  Similar to above, if you're strictly a user, you pray the developer is still in business and ask nicely for an upgrade.  If you're a user and developer, and you didn't maintain two projects, you might think to replace each static packed library subVI in the application with the original source and then rebuild the lvlibp.  Or you might think to create a new project that includes the lvlib and rebuild the lvlibp yourself.  I haven't tried it, but I hope that you can replace the original lvlibp with the lvlibp from a new project (not the one that created the original lvlibp).


This leads me to a best-practice for lvlibp: always use them as dynamic dependencies.  That way, you can maintain and develop the packed library in the same project that uses the packed library.  You'll simply reference the resources differently.


Even if you don't kudo this idea, I'm very interested to hear your feedback and experiences with the lvlibp.





Active Participant

I haven't used packed libraries, so I might be quite off-track, but would it also be necessary for the namespace of VIs in a library not to include the .lvlib/.lvlibp extension?  i.e. rather than


Active Participant

Your comment makes me wonder what happens when two differently named packed libraries contain a like-named VI and you want to use them both in the same project.  I think the lvbitp should act as a logical directory and one VI would be in conflict.


Here's some recent feedback from the developer, "I recommend having two projects: one project where you make changes to your source code and libraries, and another project where you use or test your packed library."


We encountered the same sort of issues you describe.  I think it is will be essential to implement this idea before packed project libraries become useful.  (For now we have abandoned packed project libraries entirely.)

Active Participant

As of LV2014 is appears to be imposisble to do a find and replace of PPL dependencies. So once you've replaced VIs froma lvlib with a lvlibp, you're stuck with those in that project without manually updating all call instances of the VIs in the PPL. Wow. 

Creator of the BundleMagic plugin for LabVIEW!
Proven Zealot
Status changed to: Completed

Available in LabVIEW 2019 and later. You can right-click a .lvlibp in the project and select 'Replace With...' to replace it with an .lvlib, and vice-versa.

DNatt, NI