Huge problems with AutomaticUpdateBackend [Solved]

[Wyatt]

Thanks Martin. Can you bundle up your modified AutomaticUpdater source code and send them to me -- wyatt@wyday.com?

Also, why are you setting "WorkerReportsProgress " and "WorkerSupportsCancellation"? We don't use the CancelAsync() method or the progress reporting for the BW.

[Martin]

Hi again, Wyatt.

I have done some more debugging and it turns out that:

* WorkerReportsProgress and WorkerSupportsCancellation properties do not need to be set (as you said).
* There is no need to use a new BackgroundWorker instance for each job
* All there is needed is calling System.Windows.Forms.Application.DoEvents() in "certain places" to ensure that the bw_RunWorkerCompleted eventhandler is eventually called every time!

My modified AutomaticUpdater.dll now only differs from the original one by having three DoEvents() calls added in UpdateHelper.cs - I will send the updated version of this file to you in an email.

Now only two tings really nag me:
* I really don't understand WHY this change resolves the problem - but it does! (can you explain it to me, you clever guys?
* I cannot judge if the change i made has unwanted side effects when using the AutomaticUpdater on a form. I will leave it up to you to answer that question. too.

Please let me know about your findings and what you think of it!

Regards, Martin.

[Martin]

Thank you for the updated AutomaticUpdater.dll I received by email. I have now tested it in my service and found that it works well. Thanks a lot.

- Martin.

[Wyatt]

Great, I'm glad the fixed AutomaticUpdater is working. We're still looking into the exact cause of the problems.

[Wyatt]

wyBuild 2.6.16 is now out -- this bug is fixed.

[novaleaf]

fyi, this is a terrible solution. here is why.

this causes a very problematic state for windows event-driven apps, and i suspect that this "solution" only works for the OP because it's restarting the event-loop after it was crashed.


The reason this is a very bad solution is as follows:
calling Application.DoEvents(); INVOKES THE WINDOWS EVENTS.

meaning that if you check for updates on your main thread, and RecreateBAckgroundWorker() gets called (which will happen) then you end up with a event-loop inside of your previous event-loop (and the parent event loop having not finished)

so if your app has an event loop, beware!

The reason i found this is because I use locks, and having the recursive invocation of my main app's loop caused a deadlock to occur.

[Wyatt]

We'll look into a better solution to this problem. In the meantime you can use wyUpdate as a standalone updater.

[novaleaf]

fyi i just commented the offending line out and everything seems fine so far, however I have not done usability testing yet.

[novaleaf]

also fyi, i found this because i modified my app to recreate the AutomaticUpdaterBackend object every time i check for updates.

Why do I do that? Because I found another bug, where if writing the update to disk timesout, the updater backend's state is corrupted and causes the updater to not update.

and FYI i saw this when the user's computer goes to sleep while downloading updates. i became aware of this because i assert when the AutomaticUpdaterBackend .DownloadingFailed event triggers, which said some stuff about operation timeout writing to some file under User/wc. (Sorry i didn't write down the exact message)

restarting the app caused the update to work again, so I am guessing it's the AutomaticUpdateBackend that has a bug and not the wyUpdate.exe (thus I am now recreating the AutomaticUpdateBackend when checking)