How to synchronously wait for update to complete?

[Ken Gartner]

We would like to run update.exe from our product installer, synchronously waiting until it completes and then check its return status. The problem we have is that update.exe seems to 'return' right away (with a return status of 5) even while a copy of update.exe appears to be running just fine. Apparently launching update.exe somehow dissociates itself from the caller and runs 'in the background' as far as our calling process is concerned. I assume the original update.exe process spawns another update.exe which runs while the original returns to the caller.

This means we have not been able to synchronously wait for update.exe to complete. Does anyone have some concrete suggestions for how we can use Installshield's LaunchAppAndWait() with update.exe? Can I disable the 'background' feature of update.exe so our software can wait for its true exit value?

Thanks.

Ken Gartner

[Steven Carr]

I don't think your problem is with running the Update.exe process. It does not return immedietly.

Under normal cursumstances it will run through the entire update without any problem.

The only time update.exe will restart is when the update.exe needs to update either itself or the client script side.

In this case update.exe restarts (after prompting) and this will then give you a problem as the process id changes.

[Ken Gartner]

Thanks for taking the time to reply Steven. I know about the automatic restart, but this is in the plain case. As an example, start a shell window and type the following. You will see that update.exe returns immediately (in this case with an error code of 0), but the update process is actually running in parallel and eventually pops up a Window to begin interacting with the user. Clearly the returned process is not the one that does all the work and that is partially what confuses our installer.

C:\temp\ECDE0328A\ECDE_5.0\templates>echo %ERRORLEVEL%
0

C:\temp\ECDE0328A\ECDE_5.0\templates>update.exe

C:\temp\ECDE0328A\ECDE_5.0\templates>echo %ERRORLEVEL%
0


A second point to consider is that the LaunchAppAndWait call from installshield deals with some 'windows state' of the process that is launched and its documentation says:

The setup cannot monitor an application that does not create a window. If the specified application does not create a window, the setup will continue immediately after launching the application. Note that the window for the application need not be visible, but it must exist in order for the setup to wait.

I suspect that update.exe falls into this category and that is why we are seeing problems.

-ken

[Steven Carr]

I tested it via a batch file (u.bat) with the following in it:


update
update
update

I only got a single update present at any one time.

Unfortunately i cannot test it via InstallShield as i do not use it (or have it installed). I can test it via SetupFactory if you wish ;)

BTW: Error code 5 is "The Update was aborted by the user"

Is there any issues in your client script which could be causing this problem? Does it work properly if you just run it directly from explorer?

[Steven Carr]

BTW: I also tested this with an update that hides its interface until there is an update available.

I could not see any problems with this either.

In each case i got an error code returned of zero.

[Ken Gartner]

Hi Steven --

OK, it is odd that my True Update 2.0 Update.exe will have this behavior, but yours behaves like a normal application (synchronously waiting).

Here is more demonstration of the odd behavior I have. I run PS (cygwin) to show that no update process exists prior, then launch update which immediately returns, and PS show that there is now a background update process still running. In fact I can launch four of them in quick succession and they will all run in parallel!:


C:\temp\ECDE0328B\ECDE_5.0\templates>ps -W |grep -i update

C:\temp\ECDE0328B\ECDE_5.0\templates>update

C:\temp\ECDE0328B\ECDE_5.0\templates>ps -W |grep -i update
2932 0 0 2932 ? 0 20:40:08 C:\temp\ECDE0328B\ECDE_5.0\templates\update.exe
C:\temp\ECDE0328B\ECDE_5.0\templates>update

C:\temp\ECDE0328B\ECDE_5.0\templates>update

C:\temp\ECDE0328B\ECDE_5.0\templates>update

C:\temp\ECDE0328B\ECDE_5.0\templates>ps -W |grep -i update
2932 0 0 2932 ? 0 20:40:08 C:\temp\ECDE0328B\ECDE_5.0\templates\update.exe
2812 0 0 2812 ? 0 20:43:18 C:\temp\ECDE0328B\ECDE_5.0\templates\update.exe
644 0 0 644 ? 0 20:43:19 C:\temp\ECDE0328B\ECDE_5.0\templates\update.exe
592 0 0 592 ? 0 20:43:21 C:\temp\ECDE0328B\ECDE_5.0\templates\update.exe


You are very kind to have offered to test in SetupFactory, but that should not be necessary. Perhaps I can get my version of update.exe to behave like yours and all problems will abate. Hopefully folks from IndigoRose have some ideas to offer as well.

Thanks for taking the time. I never have problems with Update.exe, itself, whether when launched from the explorer or the shell. It's just the lack of synchronous return that is driving me crazy.

Regards,

Ken

[Steven Carr]

Doing the same basic batch files with ps (you gotta love those unix style tools) and I do not get ANY Update process listed.

And as a test if i manually run the update.exe program and then run the ps line i do see a couple of windows for the single process.

One goes under the name of the "Taskbar Title", the other under the name of the current window.

BTW: I have taskbar visibility set to "Hidden"

[Steven Carr]

Ken,

If your update (via InstallShield) is returning immediately is this what you are expecting?

When you run update.exe does it display any dialogs or have you set it up to run silently (unless there is an update available)?

If it does run silently what happens if you force it to see that there is an update available? Does it detect that there is an update or does it still return immedietly?

[Mark]

Hi Ken,

I've tested this on our side with Setup Factory 7.0 and a TrueUpdate 2.0 update and everything worked properly. Setup Factory will wait for the update to return as long as I launch it with the "WaitForReturn" parameter set to true.

I would just like to make sure that you are using TrueUpdate 2.0, if you are using TrueUpdae 1.0 please let us know. Also what Installshield program are you using to launch your update?

If I run this batch file:



C:\output\TU20\TrueUpdateClient.exe
echo %ERRORLEVEL%
C:\output\TU20\TrueUpdateClient.exe
echo %ERRORLEVEL%
C:\output\TU20\TrueUpdateClient.exe
echo %ERRORLEVEL%


from the command line I get the following results:



C:\Output\TU20>run.bat
C:\Output\TU20>C:\output\TU20\TrueUpdateClient.exe
C:\Output\TU20>echo 5
5
C:\Output\TU20>C:\output\TU20\TrueUpdateClient.exe
C:\Output\TU20>echo 5
5
C:\Output\TU20>C:\output\TU20\TrueUpdateClient.exe
C:\Output\TU20>echo 0
0
C:\Output\TU20>


This was done on Windows XP SP2, I canceled the first two updates and then allowed the final update to continue. Testing with no user interface produced the same results (except that 0 was reported each time).

In general you should have no problems launching an update created with TrueUpdate 2.0 and waiting for it to return, unless it has to automatically update itself (new client data file or new client executable) in which case it will shut itself down and then spawn a new process.

As a test, please try the batch file I posted above with an update that has nothing but a Dialog.Message() action as its Client Script and let us know what the results of your test are.


Dialog.Message("Hello","Udpate");

You can also try creating a logfile with your original update, launch it (via your InstallShield setup) and then let us know what the logfile contained.

[Ken Gartner]

Thanks Mark and Steven for slogging through this with me.

I think we can ignore installshield for now, since the asynchronous behavior readily reproduces from the DOS shell.

I am using TU 2.0.0.0. This was an automagic update from a 1.0 project.

I put the several commands in a BAT file and verified that update starts up serially in this scenario, just like I want.



setlocal

set UPDATE=S:\ECDE\Otherfiles\update.exe

%UPDATE%
echo %ERRORLEVEL%

%UPDATE%
echo %ERRORLEVEL%

%UPDATE%
echo %ERRORLEVEL%

endlocal

If run it, aborting the update install I receive code 5, as expected.



C:\temp\experiment\JDBCTool>c:\temp\runupdate.bat

C:\temp\experiment\JDBCTool>setlocal

C:\temp\experiment\JDBCTool>set UPDATE=S:\ECDE\Otherfiles\update.exe

C:\temp\experiment\JDBCTool>S:\ECDE\Otherfiles\update.exe

C:\temp\experiment\JDBCTool>echo 5
5

C:\temp\experiment\JDBCTool>S:\ECDE\Otherfiles\update.exe

C:\temp\experiment\JDBCTool>echo 5
5

C:\temp\experiment\JDBCTool>S:\ECDE\Otherfiles\update.exe

C:\temp\experiment\JDBCTool>echo 5
5

C:\temp\experiment\JDBCTool>endlocal

HOWEVER, when I type the same commands directly into a CMD.EXE DOS shell (Windows XP SP2) what happens is that I get 3 different Update Available windows popped up at the same time. This is the asynchronous case that we notice from Installshield. ERRORLEVEL is not set at all, which is an indication of some shell mischief I guess.



C:\temp\experiment\JDBCTool>set ERRORLEVEL=123

C:\temp\experiment\JDBCTool>S:\ECDE\Otherfiles\update.exe

C:\temp\experiment\JDBCTool>echo %ERRORLEVEL%
123

C:\temp\experiment\JDBCTool>S:\ECDE\Otherfiles\update.exe

C:\temp\experiment\JDBCTool>echo %ERRORLEVEL%
123

C:\temp\experiment\JDBCTool>S:\ECDE\Otherfiles\update.exe

C:\temp\experiment\JDBCTool>echo %ERRORLEVEL%
123


So the big question is whether the DOS shell shows asycnhronous for you folks. If not, why does it do this for me. If so, what is Indigo Rose's recommendation for overcoming it? I can try to wrap our call to update.exe from installshield using a minimized CMD window as a workaround.

Thanks,

ken

[Mark]

Hi Ken,

After reading your post I've been fooling around with the command prompt on Windows XP SP2 and it seems as though it will launch everything asynchronously.

I have tested this with a TrueUpdate 2.0 created update, Notepad, FireFox, and Microsoft Word. On the basis of these test it seems as though this is simply the way that the command prompt launches files, not incorrect performance by TrueUpdate 2.0.

Since it is possible to launch an update synchronously using a batch file or Setup Factory 7.0, it seems as though the issue may be with the way that Install Shield is launching the file. Can you launch other files synchronously using Install Shield?

Are there any other “Wait for Return” methods available to Install Shield? Is there any documentation about the LaunchAppAndWait() action that explains how it works?


EDIT:
I found this (http://helpnet.installshield.com/robo/projects/InstallShieldXLangRef/LangrefLaunchAppAndWait.htm) page that details how the LaunchAppAndWait() action works, perhaps you could post the way that you are using the action?

[Steven Carr]

In this case i get the same behavior as yourself.

When you type udpate.exe into a cmd shell prompt it will execute the update.exe as a seperate child process.

This is the same as if you typed in


C:\temp\experiment\JDBCTool>Start S:\ECDE\Otherfiles\update.exe
However you should find it waiting if you type in


C:\temp\experiment\JDBCTool>Start /WAIT S:\ECDE\Otherfiles\update.exe

Don't know if this helps you however.