I automate the installation of Directory Opus on my system using the usual Inno Setup /VERYSILENT /NORSTART flags. Since version 13.17, the installer launches Directory Opus post-launch despite the CLI flags provided, which wasn't the case with 13.16 and earlier.
The issue with this is both that it is not a truly silent install and more importantly, it disrupts license installation post-launch which can't be done while the application is running.
Would you kindly revert this behaviour to how it was in 13.16 or provide a reliable way to avoid this behaviour?
It should be /NORESTART rather than /NORSTART, but I don't think that argument decides whether or not Opus is restarted. It's about restarting the whole computer if the installer detected files that couldn't be replaced until reboot.
Whether or not Opus is (re)started should be decided by the checkbox near the end of the installer. The setting for that should be saved with the /SAVEINF argument when the unattended install is being configured the first time, and loaded with /LOADINF when it's being run on subsequent times.
Hey Leo, thanks heaps for the reply. Sorry, I had used /NORESTART but just made a typo in my post.
I did attempt /SAVEINF with and without the checkbox ticked, but the resultant INF file is identical and doesn't provide a way to disable this checkbox.
This is the resultant INF file whether or not "Launch Directory Opus" is ticked:
[Setup]
Lang=english
Dir=C:\Program Files\GPSoftware\Directory Opus
Group=GPSoftware\Directory Opus
NoIcons=0
Tasks=desktopicon,startmenu
Please also note what I mentioned about this changing in v3.17. In v3.16 and earlier, the application would never start after installation if a silent install was used, but since v3.17, this is no longer the case.
You may test this easily in Windows sandbox via an elevated PowerShell prompt as follows:
# v3.16 works as intended.
.\DOpusInstall-13.16.exe /VERYSILENT
# v3.17 launches Directory Opus post-install, even when a silent install is used.
.\DOpusInstall-13.17.exe /VERYSILENT
You're right, there was a change in the 13.17 installer, which could have this unintended effect.
In the next update we'll make it work as it did in 13.16 by default, and add a new installer argument to get the new (13.17) behavior, so people can use both as needed.
