Is LabVIEW’s Installer Engine officially deprecated? Windows SAC making it unusable.

[thols]

I want to address the growing incompatibility between the LabVIEW Application Builder’s standard installer engine and Windows 11 Smart App Control (SAC).

The technical failure:
NI has acknowledged in KB 287957 that the legacy WinMIF/CAB-based architecture causes extreme slowdowns on Windows 11. However, on standard Windows 11 machines with SAC enabled (which is the default), the issues go much deeper:

• Extreme slowdowns: Installation can take hours as the legacy engine's file extraction triggers aggressive, real-time security scanning for every single small file.
• Total blocks on air-gapped machines: Since SAC cannot reach the cloud to verify the hundreds of extracted temp files, it often defaults to "Block" even for signed installers.
• The 63% Stall: Even with an internet connection and EV-signed binaries, we see "Forbidden by system policy" errors mid-install.

The NIPM "Solution":
NI’s recommendation to move to NI Package Manager (NIPM) is not viable for many professional distributions. External customers often demand lightweight, "clean" installers without the overhead of NIPM’s background services and infrastructure.

Current Workarounds:

1. Connect to internet: This sometimes allows SAC to verify the signature/reputation but is often impossible in secure lab/industrial environments.
2. Disable SAC: Warning! This is a permanent, one-way switch in Win11. It requires a full OS reinstall to undo.
3. Third-party (The 'Real' Fix): Migrating to Inno Setup or WiX. Using a single, modern Solid Compression binary (SHA-256 signed) works perfectly even offline.

My Question to NI:
We pay for the Application Builder license, yet its primary "Installer" output is now technically unfit for professional distribution on modern Windows environments.

Is there a roadmap to modernize the legacy engine to be SAC-compliant, or is this functionality being intentionally deprecated in favor of NIPM lock-in? Should we officially consider the built-in installer a legacy feature and move to Inno Setup for good?

[alexderjuengere]

good catch, I wonder if that is the reason, why there is the NI package manger 

[alexderjuengere]

---

@alexderjuengere wrote:

good catch, I wonder if that is the reason, why there is the NI package manger 

---

...in coexistence with the application builder...

[alexderjuengere]

oh, I mixed up NI package manager with NI package builder....

Create a Package Installer From NI Software Offline Installers
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001ECSwCAO&l=de-DE

for me, the package builder is a valid alternative for  application builder in terms of creating a clean installers, as thols pointed out

but maybe your issues are the same for both application builder and package builder?

[BertMcMahan]

---

@alexderjuengere wrote:

oh, I mixed up NI package manager with NI package builder....

Create a Package Installer From NI Software Offline Installers
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001ECSwCAO&l=de-DE

for me, the package builder is a valid alternative for  application builder in terms of creating a clean installers, as thols pointed out

but maybe your issues are the same for both application builder and package builder?

---

That shows how to install NI software (LabVIEW, TestStand, etc.). Can you use it to install your own executables?

Also, I have noticed the "takes multiple hours to install" issue for new software. I have taken to always creating two installers- one "full" one with all the runtime engines and one "upgrade only" one that only updates my own executables. It's kind of a pain to remember both and handle the two outputs, but the update installers go REALLY fast.

(It would also be nice if the output was a SINGLE file, or if you could auto-zip it or something when it gets generated.)

[alexderjuengere]

---

@BertMcMahan wrote:

---

@alexderjuengere wrote:

oh, I mixed up NI package manager with NI package builder....

Create a Package Installer From NI Software Offline Installers
https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001ECSwCAO&l=de-DE

for me, the package builder is a valid alternative for  application builder in terms of creating a clean installers, as thols pointed out

but maybe your issues are the same for both application builder and package builder?

---

That shows how to install NI software (LabVIEW, TestStand, etc.). Can you use it to install your own executables?

I use it mainly to install labview runtimes, vision runtimes, NI Max, VISA and some vision drivers at once. I have tested this with labview 2023 Q1, 2024 Q4

we keep the .exe files, which were compiled from .vis in a labview project via application builder, separately from that installer.

[BertMcMahan]

I'll have to investigate switching my runtime stuff to that installer. Seems to me that the actual built LabVIEW exe's don't take long to install, so doing those "the old way" doesn't seem to be a problem.

Any chance you could explain the difference between NI Package Manager and the Package Builder? Kinda seems to me that the Package Manager just handles installing and showing what's installed, and the Package Builder lets me make a "spec" that can run and will set up the packages the way I need them. Is that about right?

[thols]

The same issue now also happens on Windows 10 and Windows Server (2019), but the installer instead completes successfully, and when you then start the app you get strange errors (e.g. 0x464). What happens is the installer silently fails to install some components, and the uninstaller is not installed, so its a mess to cleanup. For anyone that encounters the same, this is the short way of fixing it.

Step 1: Prepare the Installer

1. Copy your installer that contains your app and runtime(s) folder to a folder in C:\ that you create, for example C:\Installers (Do NOT run from Downloads, Desktop, Network etc).
2. Right-click setup.exe > Properties. If there is an Unblock checkbox at the bottom, check it and click OK.

Step 2. Disable Blocking Security

Modern Windows security sometimes blocks the sub-installer scripts used by the installer.

1. Open Windows Security > App & browser control > Reputation-based protection settings.
2. Turn OFF:
• Check apps and files
• Smart App Control / Smart Screen for Microsoft Edge (If available, set to Off. Note: If it’s already 'On', it must be disabled to allow legacy NI installers).
• Potentially unwanted app blocking.

 If disabling the security features isn’t an option for you, you can still try with the next step:

Step 3: Run Forced Reinstall

1. Open the Start Menu, type cmd, right-click it, and select Run as Administrator.
2. Type the following command (adjust the folder name) and press Enter :

cmd

cd C:\Installers\YourFolderName\

.\install.exe /reinstall /log %userprofile%\Desktop\install_log.txt

(The /reinstall flag forces it to overwrite broken components, and the /log creates a report which you can ).

(I guess everyone moved on to InnoSetup a long time ago since I don't hear more about this)

[alexderjuengere]

---

@BertMcMahan wrote:

Any chance you could explain the difference between NI Package Manager and the Package Builder? Kinda seems to me that the Package Manager just handles installing and showing what's installed, and the Package Builder lets me make a "spec" that can run and will set up the packages the way I need them. Is that about right?

---

I think so

.

Feature	NI Package Builder	NI Package Manager (NIPM)
Primary Role	Authoring Tool (Creation)	Management Tool (Installation)
User Profile	Developer / Engineer	End-User / System Admin
Main Action	Packages files and defines rules	Installs, updates, and removes software
Dependencies	Defines what is required (e.g., Runtime)	Resolves and installs what is required
Output	Creates .nipkg files or installers	Results in a configured, ready-to-use app

[rolfk]

---

@thols wrote:

(I guess everyone moved on to InnoSetup a long time ago since I don't hear more about this)

---

I doubt it. Haven't seen any InnoSetup based LabVIEW toolkits anywhere. I mean, aside from the fact that project plugins are a pitta to create and debug, it would be absolutely not impossible to create a InnoSetup based project target option. It may not do everything you ever would like, but for a majority of applications it would be enough.