LabVIEW
Any way to speed up installers? AV is killing me...
When I run an installer on a PC without any runtime engines/drivers/etc., it takes many, many hours to complete. I'm talking 6+ easy. If I install something WITHOUT the dependencies, it takes <30 seconds.
How do I get this to go faster? We just updated LabVIEW versions, which is triggering a runtime/driver update on all of our computers. I've only tried to install to two separate PC's, but it generally has to run overnight since people are using their machines. Windows decides to reboot for updates all the dang time, too, so I come back to a PC with no dialog anywhere saying whether or not the installer even worked.
I am 100% certain this is due to security policies on our computers, as this doesn't happen for PC's that aren't on our network.
What setting can I ask our IT to turn off? Or is there some other way to get these dependencies installed that DOESN'T take (literally) a day per PC?
I'm currently using regular installers built in the dev environment, not NI packages. Would it be worth it to switch to NIPM to get some sort of speedup?
Wow, much appreciated! I did a search and found this link that didn't give me much other than "disable Smart App control".
Can anyone confirm moving from regular installers to NIPM was worth the effort? I've had some bad experiences with NIPM in the past, so I'm a little gunshy, but if it's the way to go I'll happily switch.
I would say you are lucky to just have seen slowdowns. I have had corrupt installations (on Windows 10), and complete installation stall or blocks on Windows 11.
You can ask IT to disable SAC, but that can't be reversed (this was true some months ago at least), so my guess is that they won't.
I had to move away from the old installer and now use NIPM (but I also use NIPB and a simple C# app to run NIPM etc, so our customers encounters what looks like a regular installer, that does what a regular installer should do)
NIPM does not replace the old installer we can build in LabVIEW, but the simplest replacement that should be sufficient for you is to build a package in LabVIEW and select to also build a package installer (in the settings for the package build spec). The package installer works pretty much like a regular simple installer, but it also installs NIPM for the package management.
You can create an empty package and only include the dependencies you want an installer for. That's what I do for LabVIEW runtime, VISA etc.
If you need to create installer for apps, you can create just a package for the app, and let a script install the package-installer with the dependencies first and then run the installed nipkg.exe with parameters to install the app-package.
The download installers seem to be NIPM based too, it's at least the first thing they usually want to update before they are willing to install anything else.
And my latest installation of 2026Q1 on my computer where 2025Q3 was installed took more than a day. Granted I installed most of the academic software suite, LabVIEW, all toolkits, DAQmx, IMAQ Vision, VISA, but still 24 hours is simply insane!!!
@thols wrote:
I would say you are lucky to just have seen slowdowns. I have had corrupt installations (on Windows 10), and complete installation stall or blocks on Windows 11.
You can ask IT to disable SAC, but that can't be reversed (this was true some months ago at least), so my guess is that they won't.
I had to move away from the old installer and now use NIPM (but I also use NIPB and a simple C# app to run NIPM etc, so our customers encounters what looks like a regular installer, that does what a regular installer should do)
NIPM does not replace the old installer we can build in LabVIEW, but the simplest replacement that should be sufficient for you is to build a package in LabVIEW and select to also build a package installer (in the settings for the package build spec). The package installer works pretty much like a regular simple installer, but it also installs NIPM for the package management.
You can create an empty package and only include the dependencies you want an installer for. That's what I do for LabVIEW runtime, VISA etc.
If you need to create installer for apps, you can create just a package for the app, and let a script install the package-installer with the dependencies first and then run the installed nipkg.exe with parameters to install the app-package.
I've seen some corrupted installs, too, but it's not super common.
So my apologies but I'm a little confused at "I had to move away from the old installer ... NIPM does not replace the old installer." I'm not entirely sure what NIPM is doing, then. Do you make an exe, then an installer, THEN a package? I thought it went exe -> NIPM package and you skipped the "installer" build spec.
@BertMcMahan wrote:So my apologies but I'm a little confused at "I had to move away from the old installer ... NIPM does not replace the old installer." I'm not entirely sure what NIPM is doing, then. Do you make an exe, then an installer, THEN a package? I thought it went exe -> NIPM package and you skipped the "installer" build spec.
There is an option in the package build spec to create a "Package Installer" that will include all of the dependencies and an installer executable to install everything including and through NIPM.
@crossrulz wrote:
@BertMcMahan wrote:So my apologies but I'm a little confused at "I had to move away from the old installer ... NIPM does not replace the old installer." I'm not entirely sure what NIPM is doing, then. Do you make an exe, then an installer, THEN a package? I thought it went exe -> NIPM package and you skipped the "installer" build spec.
There is an option in the package build spec to create a "Package Installer" that will include all of the dependencies and an installer executable to install everything including and through NIPM.
Does this result in a faster/better installation experience? Or does it still take forever (but at least shows dependencies)?
@BertMcMahan wrote:
@crossrulz wrote:
@BertMcMahan wrote:So my apologies but I'm a little confused at "I had to move away from the old installer ... NIPM does not replace the old installer." I'm not entirely sure what NIPM is doing, then. Do you make an exe, then an installer, THEN a package? I thought it went exe -> NIPM package and you skipped the "installer" build spec.
There is an option in the package build spec to create a "Package Installer" that will include all of the dependencies and an installer executable to install everything including and through NIPM.
Does this result in a faster/better installation experience? Or does it still take forever (but at least shows dependencies)?
If you compare the regular installer built in LabVIEW to the new package installer (or NIPB/NIPM), than it is likely to go faster, and the reason for it is described in the link that softball provided. Newer Windows 10 and 11 builds is more likely to slow down, block, stall or break the old WinMIF installer, but the details to why, if, and when depends on Windows security settings (ask IT).
My experience is that an installer I make with an app plus runtime is faster to install than the old one was when Windows didn't mess with it, but not by much. I have heard other people complaining that the NIPM-based installer is still very slow and nowhere near a reasonable install-time.
The old installer was made to look like a regular installer for the end user. The new package installer is limited but try it and see if it works for you. If you are installing for a developer, the user-experience is not important anyway, right?
