Hello all,

I know how to prepare an installshield installer for unattended install :

1. launch setup.exe -r to create a setup.iss "response file"

2. move the .iss to the setup directory

2. launch setup.exe -s to install unattended

The problem :

When I launch a setup.exe from a .cmd file I can't find a solution to wait the setup to complete...

I tried start /wait but it didn't help.

I tried start /wait setup.exe -s /w (as seen on install shield support : Q105473)

Can someone give me a little hint ?

thanks !

[sOLVED]

A lillte more googling and I found it :

unattended.sourceforge.net

start /wait setup.exe -s /SMS

my initial feeling is that it may create a child process then quit. You would have to watch and see if that is the case.

Well jondercik, the "official" site did have the parenthetic statement below

/SMS : Wait (InstallScript MSI projects only)

however the unattended.sourceforge site seems to have a bit more positive of an outcome with the switch

Unfortunately, the installer will fork a separate process and exit, meaning it will return immediately even if you run it with start /wait. Luckily, there is another option, /sms, which will cause the installer to pause until the installation completes.

Also on the "official" site

/SMS : Wait (Standard projects only)

For a Standard project, Setup.exe automatically waits for the installation to finish before exiting, so this switch (used by earlier versions of InstallShield Professional) is no longer necessary.

Which would make my question, what is a "standard MSI" as it relates to all this.

And also why is this "no longer necessary"?

Thanks gloubs for the links. Although now I'm left with more questions that I started out with. (well actually I had none until you started this thread )

Edited December 7, 200520 yr by JoeMSFN

Nice stuff to know. Maybe it will prevent me from having to write a few Auto-It scripts that watch for process to no longer exist.

The problem with Installshield installers is that the setup.exe process is just a placeholder for the actual installation file, which is an .msi file. The setup.exe process checks for the existence of the necessary supporting file versions of the Windows Installer, installs the installscript package if the setup routine requires it, and then launches the actual .msi file. Unless you use the /SMS switch, setup.exe terminates at this point and hands off complete control of the installation to the Windows Installer engine - which is why "start /wait" doesn't work. What happens is that the setup.exe process completes and closes, and thus your script happily moves right along to the next line because "hey, setup.exe is done!". The /SMS switch forces setup.exe to stay loaded until the .msi installer returns an exit code (doesn't matter which, any exit code will do), and then it terminates.

Make sense?

I wish the powers that be, the ones who actually pack these installers up, would simply use the .msi file format instead of wrapping it in a setup.exe that no one should really need anyway. Oh well, why have a standard way of doing things when it can be done so many different (incompatible) ways? <sarcasm> Why use the built-in installer engine when we can write our own!!! </sarcasm>

Edited December 8, 200520 yr by cluberti