TWebUpdate

We are using TWebUpdate.


After doing the update, when TWebUpdate launches the app it is running from C:\Users\USERNAME\AppData\Local\Temp\ rather than the install directory. The app in the install directory has been updated.

Are we doing something wrong?

Regards

Dave Craggs

If it helps, here is the last part of the log:


09/05/2017 13:06:00 : [959] Restart app in directory : W:\SVN-WORK-AREA\BSAC\CareBusinessManager\Object (Status:0) (Error:0)
09/05/2017 13:06:04 : [958] Spawn 7784 L W:\SVN-WORK-AREA\BSAC\CareBusinessManager\Object\CareBusinessManager.exe " " "C:\Users\dcraggs\AppData\Local\Temp" CareBusinessManager.exe (Status:0) (Error:0)
09/05/2017 13:06:12 : [000] UPD v2.0.4.0 started
09/05/2017 13:06:12 : [000] UPD current directory: W:\SVN-WORK-AREA\BSAC\CareBusinessManager\Object
09/05/2017 13:06:12 : [000] UPD waited from 09/05/2017 13:06:07:584 to 09/05/2017 13:06:11:732 for application close
09/05/2017 13:06:12 : [000] Upd execute CareBusinessManager.exe W:\SVN-WORK-AREA\BSAC\CareBusinessManager\Object</div>
09/05/2017 13:06:26 : [000] UPD restart W:\SVN-WORK-AREA\BSAC\CareBusinessManager\Object\CareBusinessManager.exe  
09/05/2017 13:06:26 : [000] UPD has EXE restarted

It seems to be running the spawned app.

Dave

It is normal and by design that TWebUpdate executes after downloading the updates, the app UPD.EXE and this spawned updater app in turn restarts the app, in this case, I see this is: W:\SVN-WORK-AREA\BSAC\CareBusinessManager\Object\CareBusinessManager.exe, so it does not appear to be the file from the Windows temp folder but the app from the path W:\SVN-WORK-AREA\BSAC\CareBusinessManager\Object\

No It's definitely restarting the app from the temp directory. I have a simple project that demonstrates.


Can I send it to you?

Dave

Can you please compare your .INF file settings & WebUpdate component settings with these from the sample apps we provide.

Will try and locate, but the inf file is:


[update]
newversion=2.0.0.0
localversion=SimpleWebUpdate.exe
[files]
count=1
[file1]
url=W:\SVN-WORK-AREA\OfficeCraft\Devwork\WebUpdateTest\SimpleWebUpdate\Update\SimpleWebUpdate.exe
newversion=4.0.1.53
localversion=SimpleWebUpdate.exe
[application]
appupdate=1
appname=SimpleWebUpdate.exe
appcomps=SimpleWebUpdate.exe

Is the app active directory when you start the update process

W:\SVN-WORK-AREA\OfficeCraft\Devwork\WebUpdateTest\SimpleWebUpdate\Update</span>
and do you start the update process with
WebUpdate.DoUpdate(true)?
I have sent you the sample project.

It's actually a nice way to play with TWebUpdate. I am using a separate config to create the update app  in a separate area with an updated version.

Dave

Hmm - after closing the app launched from temp, the original app is deleted.


Strange

Dave

The issue is that the update download name is exactly the same as the app name and this isn’t allowed.

Please either choose an update download file name with suffix _NEW or put the download in a CAB file.

Strange - we are using _new in production.


[update]
newversion=2.0.1.52
localversion=CareBusinessManager.exe
[files]
count=4
[file1]
url=http://webupdates.officecraft.net/Beta/CareBusinessManager/CareBusinessManager.exe_new
newversion=2.0.1.52
localversion=CareBusinessManager.exe
[file2]
url=http://webupdates.officecraft.net/Beta/CareBusinessManager/CareBusinessManager.rav
localversion=CareBusinessManager.rav
targetdir={app}
[file3]
url=http://webupdates.officecraft.net/Beta/CareBusinessManager/CareBusinessManager.chm
localversion=CareBusinessManager.chm
targetdir={app}
[file4]
url=http://webupdates.officecraft.net/Beta/CareBusinessManager/CareBusinessManager.pdf
localversion=CareBusinessManager.pdf
targetdir={app}
[application]
appupdate=1
appname=CareBusinessManager.exe
appcomps=CareBusinessManager.exe_NEW

But one ref has _new and the other _NEW - would that make a difference?

The check is case-insensitive, so I cannot see that as a reason for an issue.

Will carry on with this tomorrow. Am using custom FinalBuilder plugins to generate the inf file and deploy the files as part of an automated build and deploy.


Thanks

Dave 

Hmm - still happening but not sure why.


Have an update that worked fine on one machine, but not on another :-(

Any difference you can see when enabling logging between working vs non-working machine?