cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pd0123
Level 4

Silent install overwrites msi arguments

We have a single IS project that supports the installation of multiple products. The variation in the products is handled by passing appropriate "MSI Command Line Arguments" for the particular product (see attached picture). Now our customer wants to run the setup in a silent mode. However if they try to run the setup as setup.exe /s /v"/qn the arguments to the msi are lost(overwritten?). We do not want our customers to know about the msi command line aruguments : in other words asking them to run the setup as setup.exe /s /v"/qn /v"ALLUSERS=1" /v"PRODUCT_ID=234" is not an option.

Any idea as to why passing the /s /v"/qn parameters to setup.exe results in the msi not using the internal parameters ? Your help is much appreciated.
Labels (1)
0 Kudos
(6) Replies
snip_1415
Level 4

Hi,

I think the command line takes precedence over the MSI arguments specified in the "Releases" View of IS. So when u want to run the setup.exe in silent mode and specifies the same on cmd line then whatever is defined internally is lost.

Since your customers want to install the product as silent then why dont u propose to them 2 versions of the application; one will be silent where u can append /qn directly to the "Releases" View of IS and the other will be non-silent where /qn is not specified.

Silent: /s /v"/qn /v"ALLUSERS=1" /v"PRODUCT_ID=234" (This u will specify in the setup.exe, so customer will never know of it)
NonSilent: /s /v"ALLUSERS=1" /v"PRODUCT_ID=234" (This is what u have presently)

Is it not a possibility?
0 Kudos
pd0123
Level 4

Thanks for the reply...
Unfortunately even that is not an option. The version numbers on the 2 setups would then need to be different(as they are 2 different binaries) and the customer is very clear on not wanting that...
0 Kudos
snip_1415
Level 4

OK. If that is the case then i think its not possible to have ur internal MSI cmdline arguments ( set in "Releases" view of IS) to work.

If user launches setup.exe from cmdline with certain properties than that becomes the cmdline for msiexec and internal cmdline is ignored.

What u can do here is let user pass the silent switch to the msiexec :
setup.exe /s /v/qn

Once the msiexec is launched then u create 2 "set a property" (Type 51) custom action and hardcode the values of the properties (PRODUCT_ID, ALLUSERS) u want to the respective values

This solution will not expose ur cmdline to the end user and u will have the proper properties set during the installation.
0 Kudos
pd0123
Level 4

That is too bad 😞
I wish somebody from Installshield team can explain why all parameters to msi gets overwritten. I can understand if the underlying msi argument has the exact same name as the setup parameter...which is not in this case..
0 Kudos
pd0123
Level 4

Found the problem. Checking the log file it does look like that the properties are indeed being passed into the msi. However, it seems that the InstallUISequence is not run in the silent mode (silent mode.... duh!! )
If this is true, it would explain why the params are not being used. In our project most of them are set/used in custom actions that are only executed in the InstallUISequence.
0 Kudos
pd0123
Level 4

Params are passed when the setup is run in the silent mode. Params not not passed when setup is run in full UI mode - this is a bug in installshied verified by tech support.
0 Kudos