I'll check into this. In the meantime -- can you tell me the version of wyUpdate.exe and the version of the AutomaticUpdater you're using?
Hi,
We believe there is a bug in the AutomaticUpdater. Here are the steps to recreate:
Precondition: set UAC to lowest level so that the UAC will be displayed on doing an update.
Put an AutomaticUpdater on the page, and associate with a menu item: automaticUpdater2.MenuItem = mnuCheckForUpdates2;
On running the app, select the menu item.
It says "Checking for updates", and then "Update is ready to be installed"
Click the "Update is ready to be installed", and select "Download and Update now"
It says "Update will be installed on next start".
Click "Update will be installed on next start" and select "Install update now".
When the UAC displays, click "No" to disallow the update.
The app restarts, and it displays "X Update failed to install".
Click "X Update failed to install" and select "Try again now"
The bug: it stays in a loop "Checking for updates". It will not exit the loop until you click "Checking for updates", select "Stop checking for updates now".
If you then select the menu item again, AutomaticUpdater seems to clear out any problems it was having, and does the update OK, if you now respond yes to the UAC.
So it seems that whatever AutomaticUpdater/wyUpdate code is executed by selecting "Stop checking for updates now" allows it to recover....
We need to be able to do whatever is done on the "Stop checking for updates now"... is there an AutomaticUpdater property/method or wyUpdate command line argument, etc. that we can call to do the same as "Stop checking for updates now"?
thanks
I'll check into this. In the meantime -- can you tell me the version of wyUpdate.exe and the version of the AutomaticUpdater you're using?
Hi Sam:
Right-clicking on wyUpdate.exe, version 2.6.14.0
Right-clicking on AutomaticUpdaterWPF.dll, version 2.6.14.0
thanks
Hey Sam,
I should also mention that for our application we hide the AutomaticUpdater control, so the user only sees our custom dialog, from which we invoke AutomaticUpdater to do the actual update.
I discovered the bug when we wanted to test error handling, by saying no to the UAC, or letting the UAC sit for a while, or losing connectivity during download.
However, my testing for the bug was done with a standard AutomaticUpdater, not hiding it, etc. and I observed that the "Checking for updates" checks endlessly, which is why our custom progress dialog, after an error, would sit at 0% endlessly, since there were no automaticUpdater1_ProgressChanged events being received.
thanks
Hi Sam,
Did you check into this AutomaticUpdater UAC bug?
It's important that we get this resolved soon, since its like that some users may inadvertantly say No to the UAC, or let it sit for awhile, thereby apparently causing the AutomaticUpdater timeout.
Speaking of which, what is the timeout for AutomaticUpdater, i.e. if the user doesn't respond to the UAC for some period of time. And is there a way to change this timeout?
thanks,
Hi Sam,
Did you check into this AutomaticUpdater UAC bug?
It's important that we get this resolved soon, since its like that some users may inadvertantly say No to the UAC, or let it sit for awhile, thereby apparently causing the AutomaticUpdater timeout.
Speaking of which, what is the timeout for AutomaticUpdater, i.e. if the user doesn't respond to the UAC for some period of time. And is there a way to change this timeout?
thanks,
We can't reproduce this -- can you send me a simple test app that reproduces this behavior?
Speaking of which, what is the timeout for AutomaticUpdater, i.e. if the user doesn't respond to the UAC for some period of time. And is there a way to change this timeout?
There is no timeout. wyUpdate waits for the UAC for as long as it's open.