Wupdate not detecting need for shutdown.

I have the installs (web and single exe) working and web update works. However, the wupdate program does not seem to realize that it was called from a running program that needs to be shut down.

I am sure I just have some one setting not set correctly. The product GUIDs are there and the "Find Previous Version" function works perfectly. Once the update is done, I then get a message that the machine must be rebooted. Windows seems to have detected that an install needs to be done and that the main program needs to be shut down in order to complete that install.

Any suggestions on where to look to see what I have done wrong that is causing Wupdate.exe to not detect the running program?

Here are the contents of the Ideploy.CLI file.

[WUPDATE]
LOCAL_APP=Stockroom Inventory 5.0.7 F Single User
LOCAL_VERSION=5.0.7.006
LOCAL_CHECK=15
LOCAL_LAST=20080904
HOST_ADDRESS=www.inventorycontrolabc.com
HOST_PORT=80
HOST_DIRECTORY=SR507FG
HOST_INI=SR5FSup.ini
HOST_USERNAME=315737536578505467694A46515342486B71 68303745692F58773D3D
HOST_PASSWORD=70774A756D636936354D4B787A4643526E52 504F537A445A35513D3D
HOST_SERVICE=1

I was wondering if the problem is the "LOCAL_APP" setting. I have a feeling that the main program exe name should be there.

-O. D.-

Hello,

Could you please send the "initial" and the "web update" scripts (.sb6) to support@lindersoft.com and we'll review your configuration settings. BTW, you can replace your real username and password in the scripts with "dummy" values if you want.

Friedrich

Friedrich,

I wanted to ask one more question before sending in my scripts so as to not waste tech support's time.

I am under the assumption that wupdate.exe itself is supposed to detect that it was run by my app and then put up the message to shut down the main program. Also that wupdate.exe would automatically restart the main app when wupdate finishes.

Maybe my assumptions are not correct.

I notice that the SetupBuilder script editor has a function for "Check In Use File..." and "Run Program". Am I supposed to program those functions into the update script? I have added a "Check In Use File..." function and it does detect that the main program is running.

If I am supposed to program in the running file detection and program restart functions myself, then there is no problem, I can do that. I just thought I had better check and see if wupdate.exe was supposed to be doing those functions itself or if I should code them into my script.

-O. D.-

Hello,

No, wupdate.exe is only the web update "client". It checks checks whether a new version is available. If this is the case, it downloads and executes the "real" web update installer package. In the "real" update, you can detect if your application is still active, ask to shut it down, etc. and restart it at the end of the updating process (not under Vista/2008 please!).

Does this help?

Friedrich

Okay, some more information (based on your scripts).

The "Detect Active Application" function can only detect active 32-bit applications. It is not possible to detect active 16-bit applications.

In most cases, 16-bit applications are not "locked" when they are active. In other words, the Windows API functions to check if a file is in-use return 0 (file not in-use). It's even possible to remove those 16-bit applications while they are active. Not possible with 32/64-bit applications.

Does this help?

Friedrich

Thanks for clearing up my confusion.

It is possible that your SetupBuilder works even better than you thought. When I try to code sign the app I am currently building an install for, I get a message saying that 16 bit apps cannot be code signed. However, your "Check In Use File" function correctly reports the file as being in use or not in use as the case may be.

Anyway, using your suggestions above I now have the update program working correctly. Everbody here in the office is so impressed that all our 32 bit apps and even our one old 16 bit app can now check online for updates. We were looking for a programmer to build an online update program for us and were getting quotes in the $10K range. Then we discovered SetupBuilder.

This solves a big problem for us. Since we used to distribute version updates by mailing a CD, we only did so for updates that were critical for proper program operation. If the changes were minor or just cosmetic, we simply held off on sending those until the next major update.

Now we can find a problem today and and send the fix to all our customers all around the world on the very next day! And we do not spend a dime on postage in doing so! Slick!

In another post you mentioned that SetupBuilder could be used to do things other than install files and that tip launched us on a utility building mission. As a result, we have begun using SB6 as a utility programming tool. That is, if we have repetitive tasks to perform we just put together a SetupBuilder script to perform those steps. Also, some functions that are built in to SetupBuilder are either not available in our regular development environment or else they are very code intensive to achieve. Now we just use SetupBuilder to make a small app that performs the needed operation and then have our main app call the resulting EXE file that SetupBuilder produced. Most of these are under 200K in size and execute very quickly.



With us, SetupBuilder is not just an install maker, it has also become an easy to use utility program builder! I think we have now reached the status of "True Believer" with SetupBuilder. Thanks for creating it and maintaining it.

-O. D.-

WOW! Thank you so much for your kind words! This is music to my ears :)

You really made my day!!

Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

"point. click. ship" - that's SetupBuilder
Create Windows Vista ready installations in minutes

-- Official Comodo Code Signing and SSL Certificate Partner