LabView App in UserSpace

[michele.santucci]

Our company policies now restrict installation of software only to admin users.
Unpriviledged users cannot install software on their own without the intervention of IT techies unless is software installed in user space (C:\users\<user>\AppData).
This will cause delays in software distribution, since most of the LabView application that we build use only preinstalled NI tools\APIs (Runtimes, VISA, 488.2, DAQmx and so on) we could probably install the application in userspace ... is it allowed?
I'm using LabView 2026, I don't need to use ApplicationBuilder to create the setup. For the above reasons I can create distribution packages via third pary installers (like InstallShield, WiX).
Best regards,
 Mike

[andcadev]

Hi Michele,

Unfortunately, as far as I know, you cannot change the installation folder for the LabVIEW runtime and drivers. Moreover, almost all the NI installers require administrator privileges.

In the company I work for, it's pretty much the same. You might consider having an 'environment  setup package' containing all the runtimes and drivers you need, distributed by your IT department. Then, you could distribute the applications you build independently.

[michele.santucci]

Thanks for touryour answer but that's not what I asked. Maybe I've not been clear.

NI Runtimes, DAQmx, VISA, 488.2 etc are already installed on every machine on which our LabView Apps are distributed so there's not need to install NI software to get our apps running, we just need to deploy our apps without the request of Admin priviledges.

My question was: should an app built/compiled trough LabView (2026) run in a userspace environment (i.e. not being installed into C:\Program Files\...\) ?
I think yes because I've seen labview app running also when launched from desktop folders etc.. but I don't know if this's something that's certified to work. Is it?

Best regards,
 Mike

[andcadev]

Ops sorry.. I misunderstood you question.

The answer is yes: they can run from a user-space location.

Of course, your applications must not require administrator privileges to run. For example, they should not write to protected folders, access machine-level registry keys,etc.

[Bob_Schor]

When you ask "Can it run from a user-space location", the answer is "a qualified Yes" -- it must be a User who has access to such a "user-space location".  Let's say there are two Users of this PC -- "Developer" and "Experimenter".  Developer has the LabVIEW code, and builds the LabVIEW executable which defaults to a "builds" folder in the Developer "Document" space, where the Experimenter can't "see" it.  So the Developer simply copies the Build folder to C:\Users\Public\Public Documents\LabVIEW Builds\<Name of Project>.  Now all Users, in particular "Experimenter", will be able to run the program and access the data stored there.  Of course, it becomes the User's responsibility to move or copy it from this "Public Document" location to his own "private" User folder if multiple Users use the same machine.

One final "gotcha".  The first LabVIEW project I worked on ran a data acquisition acquisition that multiple experimenters used.  Since the Executable didn't live on each user's Desktop (because it was on the Public desktop), I made a Windows shortcut to the Executable, and now needed to put it on all the User's Desktop.  Oops, "Public Desktops" is "hidden" folder inside C:\Users\Public.  I'm not sure if this requires Admin privileges or not ...

Bob Schor

[BertMcMahan]

I can confirm that simply running executables works just fine without admin. It's installing them that requires admin rights.

Also, you can add settings, config, etc. to your ProgramData folder as part of your (environment) installer, but you need to make sure you check the "Unlock" box for that directory. That will let your users read and write from that location, which is necessary for saving things like configuration files. I use that for "system level" configuration that's independent of the user- stuff like hardware IO mapping, calibration data, etc.

Generally, changing those settings isn't in the IT domain but in the Quality domain, so you often have a little more flexibility in how you "secure" those settings. I have played around with having a "Quality" security group with Write access to configuration files that's read-only to other users, but it's kind of a pain to switch access levels mid-program and to get the UAC prompt to come up for NON-admin rights.

The simplest solution there, if your company allows it, is more "security through obscurity" where technically a user COULD edit a given file, but it's buried deep enough as to be very unlikely that they'd use it. Then you can have a simple password in your program that lets you edit the config values.

Of course you could also get into using a network database for that sort of thing, or SystemLink, or.....

[rolfk]

You can do some custom installation locations in the Installer settings for a build application. I haven't yet tried it but something like this should work:

The [Personal] folder is the <user> folder in Windows and you can then build the path to AppData in there and add an application folder in it. Then you need to mark this folder as the default application folder, which tells the Installer builder to use this destination as the main directory for your build application.

Drawback is that this will install the application only into the currently logged in user. Another user on the same system would have to reinstall it too into his own AppData folder.

[michele.santucci]

---

Drawback is that this will install the application only into the currently logged in user. Another user on the same system would have to reinstall it too into his own AppData folder.

---

That's reasonable and is the typical behaviour of every other installer that allows to install into UserSpace.
But the real question is: if you select such application target folder (User\AppData\ProgramFolder) the resulting installer executable (built trough NI Application Builder) can be run without elevated priviledges?

[Andrey_Dmitriev]

---

@michele.santucci wrote:

---

Drawback is that this will install the application only into the currently logged in user. Another user on the same system would have to reinstall it too into his own AppData folder.

---

That's reasonable and is the typical behaviour of every other installer that allows to install into UserSpace.
But the real question is: if you select such application target folder (User\AppData\ProgramFolder) the resulting installer executable (built trough NI Application Builder) can be run without elevated priviledges?

---

I don't think so. Elevated privileges will always be required. Even if they are not, you are likely to run into issues with the LabVIEW Run-Time Engine and other runtime components such as NI-DAQ, VISA, Vision, etc, and here is no way without admin rights.

The only official and working approach is to obtain administrator privileges once to install all required NI runtime components separately on the target PC (only once). After that, you can use a third-party installer such as Inno Setup (or a similar tool) to deploy your application into the user's profile folder without requiring elevated privileges.

For this type of experiment, I always recommend using a Virtual Machine for testing. Create a VM in VMware or VirtualBox, install a clean copy of Windows, save an initial snapshot, and then test your installer. This allows you to verify whether any UAC prompts appear and whether all required dependencies are installed correctly.

[michele.santucci]

---

@Andrey_Dmitriev  ha scritto:

---

@michele.santucci wrote:

---

Drawback is that this will install the application only into the currently logged in user. Another user on the same system would have to reinstall it too into his own AppData folder.

---

That's reasonable and is the typical behaviour of every other installer that allows to install into UserSpace.
But the real question is: if you select such application target folder (User\AppData\ProgramFolder) the resulting installer executable (built trough NI Application Builder) can be run without elevated priviledges?

---

I don't think so. Elevated privileges will always be required. Even if they are not, you are likely to run into issues with the LabVIEW Run-Time Engine and other runtime components such as NI-DAQ, VISA, Vision, etc, and here is no way without admin rights.

The only official and working approach is to obtain administrator privileges once to install all required NI runtime components separately on the target PC (only once). After that, you can use a third-party installer such as Inno Setup (or a similar tool) to deploy your application into the user's profile folder without requiring elevated privileges.

For this type of experiment, I always recommend using a Virtual Machine for testing. Create a VM in VMware or VirtualBox, install a clean copy of Windows, save an initial snapshot, and then test your installer. This allows you to verify whether any UAC prompts appear and whether all required dependencies are installed correctly.

---

That's exactely the approach we are using, as I mentioned in previous messages. NI runtimes and other components/drivers come pre-installed on our computers, so there is no need to reinstall them. I do not recall whether the LV runtime is a mandatory component when creating installers via the Application Builder (in which case administrative rights are required), but as I said, I can simply use a different installer like WiX ,which I prefer over InnoSetup, to create a UserSpace installer and in this case administrative rights are not needed.