Installing to LabVIEW Data with an NI Package

[croohcifer]

Hello,

I'm building a package that contains a bunch of LabVIEW plugin features like VI Analyzer tests, Quick Drop plugins, Quick Drop templates, right click menus, etc. that we use frequently at my company.  For many of these items, you can install the components either in a <LabVIEW Data> directory (in which case they work for multiple versions of LabVIEW) or in a LabVIEW-version-specific directory in <Program Files>.  We have users of both 2016 and 2018, so I'd ideally like to make one package and install to <LabVIEW Data>.  I could make version-specific packages, but with some components like custom VI Analyzer tests, the help seems to suggest that the default data directory is the ONLY place you can add them.

We use NI Packages to distribute all of our internal tools, but this is the first time I've run into a case where I'm not sure I can use a package to directly do what I need.  The Installer build type has a "[Personal]" directory (C:\Users\'user_name'\Documents\, which is where "LabVIEW Data" lives) as a selectable destination, but the NI Package build type doesn't seem to support that.  I could make an EXE that copies files like custom VI Analyzer tests to <LabVIEW Data> and run it as a action in my Package, but that seems like a silly workaround to something that an NI Package should probably support.

Any ideas?  Am I missing something obvious?  Is there a good reason why NI Packages don't support this destination directory?

I appreciate the help!

David

[WhiteA]

Are you running into any specific errors when trying this? Could this be a feed issue with the destinations?

[croohcifer]

There's no error.  It is literally just not an option.  Here's the option to install to the [Personal] (i.e., default data) directory with an installer:

Here are the options for an NI Package:

Note the lack of a [Personal] directory or its equivalent.  Thus, I cannot install content to the <LabVIEW Data> directory natively from an NI Package without using some other kind of EXE or batch file I can include in the "Advanced" tab.  As mentioned above, that seems like a needlessly complex workaround for something that seemingly could and should be included in the NI Package build properties.  Again, I could be mistaken about the way an NI Package works, and there could be a totally valid reason to not include that directory or even a better existing workaround.  Just looking if someone has run into this.  If it's an oversight, then I'd like a feature requested to add this directory.  If there's a reason to not include it, then I'd like an explanation as to why and, ideally, a suggestion of a workaround if there's a better one than the helper EXE.

Thanks!

[Hooovahh]

I think you have a valid issue and NI should address it.  But that being said why isn't "Public Documents\LabVIEW Data" an option for the installed location?  Won't that get picked up too?  Do you expect different users to use the same computer, and want different things installed there?

[croohcifer]

"But that being said why isn't "Public Documents\LabVIEW Data" an option for the installed location?  Won't that get picked up too?"

I definitely considered this.  To answer the question, no, it doesn't get picked up by default.  You can change the default data directory in Options>>Paths, but you can only have ONE Default Data Directory path (not multiple like you can set with the VI Search Path directories), so if I distributed a LabVIEW INI file with my package (or used an EXE to modify the INI file), I could overwrite the Default Data Dircetory INI token with "C:\Users\Public\Documents\LabVIEW Data".  However, if I did, I could see three possible negative effects. 

1. Any "C:\Users\username\Documents\LabVIEW Data" contents (including other plugins the user may want) would be ignored.
2. There would be a burden on every LabVIEW developer to know about this directory change and change their habits to put their own custom content into the public directory.
3. Anything I installed would apply to all users on that PC.

The first two are the main annoyances.  Three is probably not an issue for us, but I'd still generally like to work with the standard <LabVIEW Data> directory to avoid other unforeseen issues if possible.