We are using TWebUpdate.
If it helps, here is the last part of the log:
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 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:
Is the app active directory when you start the update process
Hmm - after closing the app launched from temp, the original app is deleted.
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.
But one ref has _new and the other _NEW - would that make a difference?[update]newversion=2.0.1.52localversion=CareBusinessManager.exe[files]count=4[file1]newversion=2.0.1.52localversion=CareBusinessManager.exe[file2]localversion=CareBusinessManager.ravtargetdir={app}[file3]localversion=CareBusinessManager.chmtargetdir={app}[file4]localversion=CareBusinessManager.pdftargetdir={app}[application]appupdate=1appname=CareBusinessManager.exeappcomps=CareBusinessManager.exe_NEW
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.
Hmm - still happening but not sure why.
Any difference you can see when enabling logging between working vs non-working machine?