How to reset Automatic Updater?

If he chooses NOT to update this time I want to *reset* the Automatic Updater control, so that it forgets all about having ever seen the update for the current version, but so far I have not been successful in doing that. As a consequence I cannot get the Automatic Updater control to perform any update checks after this point. Is resetting the Automatic Updater control possible at all?

This is a bug. The AutomaticUpdater should invalidate the cache after certain period. We'll fix this for 2.5.25. We'll also add a function to manually clear the cache.

Thank you very much. Any idea about when 2.5.25 will be out?

- Martin

We're trying to get it out by the end of the week to fix a few of these issues.

Just a update: we're shooting for a release on Tuesday night (6/15).

We're running our final tests. If there are no regressions then this should be out tomorrow morning.

Very nice.

wyBuild 2.5.25 is out now. With wyUpdate & AutomaticUpdater v2.5.25 you can call ForceCheckForUpdates(true) and it will discard previous update information and recheck with your servers.

Hi, Wyatt and Sam.

Thank you for your efforts in making it possible to reset Automatic Updater - however, it seems that the new ForceCheckForUpdate( bool recheck) does not not work as expected (or at least, as I expect it to work from your explanation in this thread)...

Checking for updates the first time works Ok - the UpdateAvailable event is fired.

Now, the updated version of AutomaticUpdater should allow me to do a new check, so I do as follows:

1) First I take down the web server holding the update files

2) Then I call ForceCheckForUpdate( true ) to make a new check. This call should also make AutomaticUpdater forget everything about the update discovered during the last call. I would expect this call to fire the "CheckingFailed" event, like it usually does.

But, when calling ForceCheckForUpdates( true ) in step 2, the only event fired is "BeforeChecking", and afterwards the "UpdateStepOn" property still shows UpdateStepOn.UpdateAvailable. Nothing else happens. No event fired telling about the outcome of the check. ForceCheckForUpdates( true ) returns immediately with value true.

Sorry to say, but your testing efforts prior to this release do not impress me much... (unless I have misunderstood something importent?).

-Martin

But, when calling ForceCheckForUpdates( true ) in step 2, the only event fired is "BeforeChecking", and afterwards the "UpdateStepOn" property still shows UpdateStepOn.UpdateAvailable. Nothing else happens. No event fired telling about the outcome of the check. ForceCheckForUpdates( true ) returns immediately with value true.

ForceCheckForUpdates(..) always returns immediately, and only return whether the updater has begun or not. It passes the work off to wyUpdate.exe to complete.

As far as events being fired, "UpdateAvailable" is called upon a successful update check and "CheckingFailed" is called upon the failure to check. Are neither one of these events being called? If you look on your form, is the AutomaticUpdater instance showing the spinning icon infinitely?

Also, I will not a behavior issue of ForceCheckForUpdates(true). If you have a pending downloaded update that needs to be installed it will return True when it should really return False. We'll be releasing a fixed version of the AutomaticUpdater either today or tomorrow to fix this issue.

Do you have an update already downloaded when you call ForceCheckForUpdates(true)?

Sorry to say, but your testing efforts prior to this release do not impress me much... (unless I have misunderstood something importent?).

I'm sorry. We try take make our test cases have as wide a coverage as we can imagine. But often our imagination fails us.

We'll try to improve our efforts.

Hi Wyatt and thank you for your answer.

I'm at home now, so I can't tell you what the AutomaticUpdater looks like on the form, but I'll check on monday (the updater is hidden on my form, must unhide and check on monday).

But I can tell you that neither the "UpdateAvailable" nor the "CheckingFailed" event was fired in the scenario I described.

Also, I did *not* have any update already downloaded when I called ForceCheckForUpdate(true). The AutomaticUpdater runs in "DoNothing"-mode and hence it does not download anything by itself (and I did not make any calls to the InstallNow() method...).

I think you should have no trouble reproducing the error using the scenario I described? I just used another machine at my office as a test web server and added an entry to the c:\windows\system32\drivers\etc\hosts file on my test machine to redirect the call to my test web server (and not to the Internet).

- Martin

I'll try some different ways of reproducing this problem, but from all of our tests "UpdateAvailable" and "CheckingFailed" are called when they should be.

Hi again.

If it is of any help to you, I can tell you that I use the -updatesite and -server command line parameters to define the update site (together with "%updatesite%/%file%" in wyBuild).

-Martin.

Ok Wyatt.

Now I've checked what AutomaticUpdater actually looks like on my form:

First I do a call to ForceCheckForUpdate(true), that actually finds an available update on my web server. The control shows up as an animated circle and then turns into a golden star with an up-arrow inside in the center. When I move the mouse pointer on top of it, it displays the text: "Update is ready to be installed." The "UpdateAvailable" event is fired as well. Everything ok so far.

Next, I prevent my test machine from reaching the web server, and I do another call to ForceCheckForUpdate(true). Now the golden star immediately turns into a red X. If I move the mouse cursor on top of the red X, it displays the text: "Checking for updates". This seems *not* to be correct. And neither the "UpdateAvailable" event nor the "CheckingFailed" event is fired.

Normally, while the checking process is ongoing, the little animated circle is displayed and not the red X. And, once the checking process has failed, the red X is normally displayed together with the text: "Failed to check for updates."

Hope this info helps you find the bug.

-Martin

I'm going to try to reproduce this - something's wrong.

I'm not able to reproduce this - I'm going to need to do a remote desktop to investigate this. Are you free sometime this week?

Or if you can reproduce this in an simple example project that would be even better. You could send it to wyatt@wyday.com.

Hi, Wyatt.

Thank you very much for your big efforts in this case. I'm having a day off today, but tomorrow I'll see if I can produce a small working example showing the problem. I'll be in touch.

Best regards,

Martin.

Hi, Wyatt - I have news!

While trying to make a small example showing you the problem, I discovered that I had still code left, that programmatically deletes all cached data (the "wc" folder and the "wyUpdate AU" folder) prior to my second ForceCheckForUpdate(true) call.

It turned out, that this code caused the problem (try for yourself to delete these folders prior to an update check, that would otherwise fire the "UpdateCheckFailed" event).

Now, having removed that code, the updater always finishes properly by fireing either the "UpdateAvailable" event or the "UpdateCheckFailed" event. No problem.

However, my original problem (that started this thread in the first place!), seems not yet to have been solved: I still can't get the Automatic Updater control to forget about having seen an update that I chose *not* to install:

1) I check for an update that is actually available (f.ex. on a local media), and this update is correctly reported by Automatic Updater control. OK.

2) I check again, but this time I reference another place, where updates cannot be found. Despite of no update files present (or other blocking conditions, that would normally cause the "UpdateCheckFailed" event to be fired) the Automatic Updater still fires the "UpdateAvailable" event, appearently based on the cached data. It seems, that the updater control *doesn't even try* to check, because it relies totally on the cached data?

I'm very sorry to have meslead you with my faulty code, I hope not to have caused you too much trouble - I will not let that happen again!

-Martin

2) I check again, but this time I reference another place, where updates cannot be found. Despite of no update files present (or other blocking conditions, that would normally cause the "UpdateCheckFailed" event to be fired) the Automatic Updater still fires the "UpdateAvailable" event, appearently based on the cached data. It seems, that the updater control *doesn't even try* to check, because it relies totally on the cached data?

Are you changing the wyUpdateCommandline? Is that how you're referencing the new site?

If so, I can tell you why it's failing - wyUpdate is already running in the background, thus there's no reason to start a new instance. Meaning the new commandline arguments won't get passed to wyUpdate.

Everything will work fine across multiple starts of your app, because wyUpdate is only called when there's something for it to do (rechecking, downloading, updating, etc.).

My question is this - will you be checking multiple times within a single run of your application. I know you are now, when debugging your app, but is this done in practice?

The reason I ask, is that the idea you're suggesting is bordering on a custom hack for a feature that will be satisfied in the near future. If I'm understanding your use case, what you need to do is deliver standalone patches (which we're targeting for wyBuild 2.7).

I'm very sorry to have meslead you with my faulty code, I hope not to have caused you too much trouble - I will not let that happen again!

No problem, I'm glad you got it solved.

Are you changing the wyUpdateCommandline? Is that how you're referencing the new site?

That is excactly what I do!

My question is this - will you be checking multiple times within a single run of your application. I know you are now, when debugging your app, but is this done in practice?

Yes it is. My app is a server app, and all my customers depend on having it running 24h. This is also the reason why they may choose *not* to update every single time they have a chance. Furthermore, some of my customers don't have Internet access (at least not all the time, and then often with only very limited bandwidth), and those customers need to be able to update from local update files too.

Until wyBuild 2.7 comes around: Will it work for me to (programmatically) kill any running instance of wyUpdate.exe prior to checking any new site (in order to get wyUpdate.exe restarted with new command line parameters)?

Until wyBuild 2.7 comes around: Will it work for me to (programmatically) kill any running instance of wyUpdate.exe prior to checking any new site (in order to get wyUpdate.exe restarted with new command line parameters)?

Yes - but make sure it's your copy of wyUpdate you're killing.

Also, we'll be releasing the AutomaticUpdater source code next week as part of the wyBuild 2.6 release. You'll be able to customize the AutomaticUpdater to meet your unique needs.

Hi Wyatt.

Everything is working for me now. Just before any new check I kill wyUpdate.exe (if running) and delete the "wc" folder - that's it!

Thank you again for participating that much in my special needs.

-Martin.

You shouldn't need to delete the "wc" folder. Just kill wyUpdate and call ForceCheckForUpdate(true);

If you delete the wc folder then you'll be clearing the cache for all programs that use wyUpdate. Plus, the "wc" folder isn't guaranteed to be used in future versions of wyUpdate. (It's already changed once since v2.5.0).

Does killing wyUpdate followed by a "ForceCheckForUpdate(true);" call work for you?

Yes, seems it does. Don't know why I found it necessary to delete the "wc" folder too - now I don't!

Thank you.