Package Build Spec - Installing to NI vi.lib or user.lib directory

[WillToth]

Hi,

I'm trying to build a package compatible with NI Package Manager by using the Build Specifications --> Package option in LabVIEW 2018. I want to include some VIs that are installed to vi.lib or user.lib. On the build specification page, there is no root destination for Program Files/National Instruments/LabVIEW 2018/...

I can manually create it as below:

My concern with this method is for people who have installed LabVIEW not in this location, or for folks who do not have LabVIEW installed. Is my build spec guaranteed to always find the correct 'LabVIEW 2018' directory, or is there another method I should use to achieve this? 

Thanks.

[DillonL]

Hello,

Have you referenced the NI Package Manager Manual?  I think his section of it you might find useful:

Assembling a File Package

[WillToth]

Hi Dillon,

Thanks for the quick response. It looks like the root directory is available based on this link http://www.ni.com/documentation/en/ni-package-manager/latest/manual/installation-target-roots/

Since the LabVIEW 2018 build specification is the quickest way for me to actually build the package as part of my project, is it possible to just specify that there? That would be way easier than having to take an extra step, and most of the other root options are already there.

Otherwise the next easiest would likely be to use the command line package build option as a post build step and remove the 'package' build specification, but this is a bit more involved.

[SergioR]

I've been considering NI Package Manager to deploy and manage drivers, but this limitation is holding me back. Same as mentioned here, I cannot find a way to specify default LabVIEW directories in the package build specification destinations window.

Is anyone aware of plans to improve this in the near future?

Thanks!

[Hooovahh]

NI Packages can be used for source code, but in general you're going to have a bad time.  NIPM is most useful (at the moment) for deploying built binaries or applications.  Creating packages which are you applications, which depend on other packages, which can be NI drivers, NI Run-times, or other NIPM packages you build. 

LabVIEW reuse is still best handled in VIPM.  For instance if you build a VIPM package for reuse that package can be installed in that version of LabVIEW or any newer version without having to make a new package.  NIPM packages however will (as you've noticed) install to a specific file location.  And if that location is <Root>\Program Files (x86)\National Instruments\LabVIEW 2018\... then you won't be able to install that in LabVIEW 2019.  You'll need to make a new package for that version of LabVIEW.  Same for 32-bit, or 64-bit LabVIEW where VIPM just handles that.  NIPM also doesn't have things like package dependency scanning, palette editing, locking VIs, or editing descriptions, or running VIs as a Pre-Post Build/Install/Uninstall operation.  All things VIPM does pretty well.

NI is prioritizing NIPM's features, and they thought the gap in package management was on the deployment side, which is why they are focusing there first.  They probably figured VIPM had things more or less handled on the reuse side, and would try to have those features better handled in the future.

Here is a recent presentation I gave at our local user group.  I'll be presenting an updated one similar to this at NI Week this year.

[SergioR]

Thanks for the insight, and by the way, great content on your user group presentation. You've given me more to think about 🙂