Hi,
I have my UA set up with UpdateType = CheckAndDownload. It's also invisible.
DaysBetweenChecks = 1
My explicit check action looks like this:
switch (automaticUpdater.UpdateStepOn) { case UpdateStepOn.Nothing: // main case case UpdateStepOn.UpdateAvailable: // may happen XtraMessageBox.Show(Properties.Resources.MsgAutoUpdateWillCheckInTheBackground); _forcefullyCheckedForUpdates = true; automaticUpdater.ForceCheckForUpdate(false); break; [...] }
For some reason, on many machines the discovery phase will sometimes end up in UpdateAvailable instead of UpdateDownloaded. It's not my main issue, but I'll welcome any lead.
The problem is that neither the code above nor the daily automatic check will help the update move to the next step. Nothing will ever happen.
The explicit check could be fixed by passing "true" to ForceCheckForUpdate() in order to start from scratch. Although that should not be needed.
The Automatic check I cannot master and it seems to always call this.forceCheck(false, sender == null)which will do nothing.
Thanks for your help.
The problem is that neither the code above nor the daily automatic check will help the update move to the next step. Nothing will ever happen.
With the UpdateType set to CheckAndDownload it stops at downloading the update. You have to install the update using the "InstallNow()" function (e.g. automaticUpdater.InstallNow() ).
Tell me if this helps.
Hi Sam,
This is exactly what I do. This works on most client machines.
The problems comes when, for a reason I can't explain, the AutomaticUpdater gets stuck at UpdateAvailable and never starts the download.At this point, - ForceCheckForUpdates(false) does nothing - and when the AU fires, it does nothing too.
Are you catching exceptions to just hide them? That is are you doing something like this:
try{ automaticUpdater.ForceCheckForUpdates(false);}catch (Exception e) { }If so, don't.
Also, can you send me an example project with step by instructions on how to reproduce this behavior? Send it to wyatt@wyday.com
😲 Nope. Eating exceptions is not in my habits.
I wish I could reproduce the pb at will. It happens a fair lot on client machines. I ended up in this situation myself only once. Not sure yet, but I think it has to do with the automatic check firing in the middle of the explicit check, or the other way around.
Clearing the wyUpdate cache would fix the problem of course.
BTW, there is now another odd situation users seem to face often: an explicit or automatic check would never return and leave the component in "Checking" state for ever.
Clearing the cache or issuing a standalone update would work around the problem.
And yes UpdateType in set to CheckAndDownload.
:shock:
BTW, there is now another odd situation users seem to face often: an explicit or automatic check would never return and leave the component in "Checking" state for ever.
Clearing the cache or issuing a standalone update would work around the problem.
That problem seems to be related/similar to the one I'm having here: https://wyday.com/forum/t/363/cannot-update-application-after-declining-uac-closing-app/
Hi,
I came across a scenario that consistently reproduces the "stuck in UpdateStepOn = Checking" problem.
- I'm in a situation where UpdateStepOn == UpdateAvailable at application startup.- UpdateType is set to DoNothing- KeepHidden = true- I now call ForceCheckForUpdate(true)- At some point, a message comes back from the pipe and UpdateHelper.pipeClient_MessageReceived is called.- In turn, UpdateHelper.ProcessReceivedMessage is called.- In ProcessReceivedMessage, execution goes through the "if (data.Action == UpdateAction.NewWyUpdateProcess)" branch.- This is where Process.GetProcessById(data.ProcessID); will raise an ArgumentException basically saying (translated from French) that "No process is currently running with the ID xxxx". - Unfortunately, no one will ever know about this error as you eat the exception up the call stack in pipeClient_MessageReceived.
=> Now we're stuck in "UpdateStepOn == Checking" for good.
Generally speaking, I found that this "catch {}" is obfuscating a lot of my problems.
NB: Sorry I can't give you line numbers as I had to tweak your code to make it compile under VS2005.
I'll look into this.
Using the method you described I haven't been able reproduce this problem. Are you checking for updates from multiple instances of your app? Even that shouldn't cause a problem, but I'm trying to think of ways to reproduce this.
Sorry for the late reply. I must have overlooked the mail notification.
I'm afraid I now can't reproduce the pb either. Maybe the error was bound to the state of my "wy" folders at the time I wrote. Or maybe I missed a detail in my explanation.
I think the main point is that, if anything goes wrong inside UpdateHelper.ProcessReceivedMessage(), the thrown exception, whatever its cause (misuse or bug), will be eaten in pipeClient_MessageReceived() and it will make it much harder to understand and fix the problem.
I see you already have a comment about that in pipeClient_MessageReceived():// TODO: remove try-catch block OR handle the error some other way
