After the original post, I thought maybe if I programmatically changed the UpdateType from OnlyCheck to Automatic and then triggered InstallNow there would be an immediate update, but it didn't make a difference. Still just extracted and downloaded the update but waited until next app start to install.
Update waits until app restart
I'm building a custom UI for my app and wondering if my results are expected.
I'm using VB.NET 2008 on XP and my target platforms are XP and above (so I'm on the .NET 2.0 deployment) and version 2.6.4.0
1. I set the control to UpdateType = OnlyCheck.
2. I have a variable, UpdateAvailable that I set through the UpdateAvailable event.
3. If there is an update available, I enable a download/update process. What I would like to do is offer: update now, update at closing, update at next startup.
4. I force an install with .InstallNow()
I monitor the events & have a timer (for testing) to check UpdateStepOn.
Events monitored: ProgressChanged, ReadyToBeInstalled, UpdateAvailable, UpToDate, DownloadingOrExtractingFailed, UpdateFailed, UpdateSuccessful.
I get:Downloading Update [Step]Extracting Update [Step]ReadyToBeInstalled [Event]
Nothing else happens. I close my app and on restarting it the update occurs.
Three questions:
1. Is there a property that I can check for update available?
2. I can tell that the update has been downloaded & extracted. Is there a method where I can push it to go ahead and install it on demand rather than on next startup?
3. When I use the control automatic process, there's a lag (in seconds) between closing the app and the wyBuild updating screen. Is there anything that can speed that up? The lag is noticeable and I can an end-user starting to click things thinking the app has gone to sleep.
One thing I noticed is that if I set the control to .Visible=false, when I .ForceCheckForUpdate() the control becomes visible and remains visible. If .Visible=true & .KeepHidden=true, the control is always visible. I have to set .Visible=false and .KeepHidden=true to keep the control on the form from ever showing. I don't know if this is expected.
I admit to being a rookie, but I can't find anything I've overlooked.
Thanks,
Mark.
This sounds like a bug, but I can't reproduce it.
Can I ask what OS you're running (XP, Vista, Win 7)? Also, is there any chance I could see your code (or an example that exhibits the same behavior)?
My development machine is Windows XP. I don't think I can upload to the forum, so I've PM'd you with a URL to the form. It's just a simple VB form for experimenting with wyBuild.
I'll check this out.
I can reproduce this only occasionally, unfortunately. This leads me to believe it's a race condition in the multi-process communication code. I'm tracking down the root cause of this problem.
I know troubleshooting an intermittent problem is one of the greater pains in debugging.
I'm trying to finalize my user-documentation and about to have the product release & major promotion. If you could at least give me a logic check whether this is a solid update process for a custom UI I would really appreciate it.
1. Set control to .UpdateType = OnlyCheck. (Also .Visible=false and .KeepHidden=true to keep the control hidden)2. Watch the UpdateAvailable event to see if an update is available (i.e. there is no property I could check)3. If there is an update, offer: update now, update at closing, and ask me later4. At the right time, force install with .InstallNow()
1. Set control to .UpdateType = OnlyCheck. (Also .Visible=false and .KeepHidden=true to keep the control hidden)
Honestly, you should set UpdateType to "Automatic". Here's why: if you set the UpdateType to "OnlyCheck" then you're forcing your users to make a decision. This decision is "Do I update?". Then they ask themselves a bunch of questions only you (and your company) can answer:
- Does this break my existing work?
- How long will this take?
- What if the update fails, will I be screwed?
- Etc., etc., etc.
See Joel Spolsky's Simplicity vs. Choice.
If you set the AutomaticUpdater to "Automatic", then you can handle all of the details, and you're bothering the user a whole lot less.
Watch the UpdateAvailable event to see if an update is available (i.e. there is no property I could check)
And you can also use the UpdateStepOn property. See: AutomaticUpdater members.
3. If there is an update, offer: update now, update at closing, and ask me later4. At the right time, force install with .InstallNow()
Yes and yes. But I still strongly recommend you set the UpdateType to Automatic.
It seems we have similar design goals, except mine may be even a little more conservative. If there's no update, don't involve the end-user and don't show an icon/control for them to fidget with. They can go through the entire update process and never have to do anything.
Here's what I've implemented and am pretty happy with it. I've tested the nominal paths and will try some more of the error paths.
I'm putting the control on a panel (actually a GroupControl), with UpdateType=Automatic.
If there's no update (as determined by the event UpToDate) or there's no internet connection, the panel remains not visible.
If there's an update (as determined by the event ReadyToBeInstalled), the panel is shown and they get all of the benefits the control has (view change description, update now, or (default) update on next start). To keep from having the accordian effect with the control, I set minimumsize & maximumsize to 250,18 and it stays expanded.
This is a very clean and simple solution for me. It seems when I start using the Visible and KeepHidden properties, I get some odd results so the panel lets me have all of the control functionality and I can manage when to involve the end-user.