My Latest Article: Keep your Apps Fresh with the MS Updater Application Block
I've been lucky enough to have another article published on DevX - Keep your Apps Fresh with the MS Updater Application Block - this covers the rationale behind self-updating "smart clients" and provides step-by-step instructions for using the MS Updater Application Block. I'd be happy to have any feedback!
posted by Adam Young @ 1:24 pm
6 comments
6 Comments:
Hi schildb - not sure what script you're referring to, as I didn't post any code with the article; if you're having problems with the VB version of the Updater, you should reply check out the Updater community on GotDotNet (http://www.gotdotnet.com/workspaces/workspace.aspx?id=83c68646-befb-4586-ba9f-fdf1301902f5). Otherwise, let me know exactly what you're after and I'll see what I can do!
Hi Adam,
I liked your article on Self Updating apps. However, in the section where you describe design flaws and possible solutions, I would like to draw your attention to the situation where in the user does not want to download the updates. You suggested to use a dialog box / messageBox and take input from the user ... thereby blocking the thread. I tried implementing this solution and used your idea to overcome this very case. Turns out that if even if i give a message box to the user, it does not solve the problem. If i simply do not click either Ok or Cancel, the download is completed in the background. It does not pause the updater thread and then resume it. Instead the updater thread runs separately from the winform and both of them talk to each other only when the StopUpdater() is called. Could you please look into this issue. I came up with a solution, but am not completely satisfied with it.
Hi - I'm not going to post code here, so if you want more than the below you'll have to leave something tangible for me to contact you...
What you should do is:
1. Declare a private field of type thread (this will be the thread you spawn the updater on); also, another field to hold a reference to ApplicationUpdateManager - you'll need these to be fields so you can update them in event handler code;
2. In your method where you kick off the updater, create an instance of the ApplicationUpdateManager;
3. Wire up the events - in particular, hook up the UpdateAvailable event;
4. Start the updater on a new thread - create your thread (see step 1), and use a ThreadStart to hold a reference to the updater.StartUpdater method;
5. Start this thread;
6. in your handler for the UpdateAvailable event, pop a dialog;
7. the thread should be suspended at this point;
8. if the user rejects the download, call updater.StopUpdater();
9. Also, if the updater's thread (the one you spawned in step 5) is not null, join the thread (passing a suitable timeout);
10. if the join is successful, then call Interupt() on the thread;
Hope this helps point the way...
A.
Hello Adam,
A quick question. To eliminate the issue of absolute links for the ClientConfiguration section -> TempDir set : should my config file look like
< tempDir>..\newFiles< / tempDir>
and the code part , u asked to remove the Path.IsPathRooted check. Should i leave it as this ?
'If Path.IsPathRooted(Value) Then
_tempDir = Value
'Else
' _tempDir = Path.Combine(_baseDir, Value)
'End If
or should i leave the _tempDir = Path.combine(_baseDir, value) too.
Great Article!
But i'm having a litle problem.
In the AppStart Overview you have the following in C#
-----------------------------------
// Add the following lines to ensure that AppStart
// terminates when the app process exits:
_process.EnableRaisingEvents = true;
_process.Exited += new EventHandler(process_Exited);
-----------------------------------
Can You translate it to VB?
And another thing...
-----------------------------------
The process_Exited() method (helpfully created for you by Visual Studio) should stop the Application Updater if it is running, and also kill the AppStart process with the line:
Environment.Exit(0);.
-----------------------------------
My Visual Studio doesn't create anything. Help?! (always in VB, please)
RagingKore
ragingkore@hotmail.com
RagingKore - sorry, man - I don't do VB. To be honest, the conversion should be easy;
_process.EnableRaisingEvents = true;
you're just setting the EnableRaisingEvents property of the _process to true. Will be the same in VB.
_process.Exited += new EventHandler(process_Exited);
You're pointing the Exited event, exposed by the _process object at a method (process_Exited) that will be invoked when the event fires. Apparently, VB makes this easy for you to do this kind of thing, but you should read up on events and delegates in VB: http://www.dotnetextreme.com/code/eventhandling.asp
I tink you just use similar code, but put AddressOf(process_Exited). Like I say, you should really look up this stuff for yourself so you know what's going on.
You should also check out the VB examples that come with the block.
The process_Exited() method won't be created for you in VB as it is in C# as you attach the event handler. Just create a method that has the same signature as the EventHandler delegate. In there is where you put your call to Environment.Exit(). so, your method will look like this:
private sub process_Exited(sender As object, e as EventArgs)
Environment.Exit(0)
End Sub
Excuse my hatchet-job, but I'm working from memory (syntax, casing, may be wrong).
Post a Comment
<< Home