Scott Hanselman

NOTE: If you haven't read the first post in this series, I would encourage you do to that first, or check out the BabySmash category. Also check out http://windowsclient.net/ for more developer info on WPF.

BACKGROUND: This is one of a series of posts on learning WPF. I wrote an application for my 2 year old using WPF, but as I'm a Win32-minded programmer, my working app is full of Win32-isms. It's not a good example of a WPF application even though it uses the technology. I'm calling on community (that's you, Dear Reader) to blog about your solutions to different (horrible) selections of my code. You can get the code http://www.codeplex.com/babysmash. Post your solutions on your blog, in the comments, or in the Feedback and we'll all learn WPF together. Pick a single line, a section, or subsystem or the whole app!

One of the pieces of feedback on BabySmash! was that even though people like that the application automatically updates (via ClickOnce) when they sit down to play BabySmash! their babies want to play it NOW. They didn't like that it tries to update itself when you launch it.

When you setup a ClickOnce application, you get a few choices. You can have the application check for updates before it starts and applying updates before it starts, or you can have it check after it starts and install the updates the next time it starts up. Or, you can say Don't Check For Updates.

I personally find this dialog a little confusing. What this really means is "I'll check manually in code."

At this point, I'm still deploying my app as a ClickOnce app, but now the actual updating is up to me. I used to pop up the Options dialog every time the app started, but again, folks complained, so I had to figure out a way to let them know that an update is available without "stopping the action."

When the app starts up now, it fires of a call to CheckForUpdateAsync from inside System.Deployment.Application and listens for a response. This happens in the background (hence "async"):

if (ApplicationDeployment.IsNetworkDeployed)
{
   ApplicationDeployment deployment = ApplicationDeployment.CurrentDeployment;
   deployment.CheckForUpdateCompleted += deployment_CheckForUpdateCompleted;
   try
   {
      deployment.CheckForUpdateAsync();
   }
   catch (InvalidOperationException e)
   {
      Debug.WriteLine(e.ToString());
   }
}

If there is an update, I show a label in each MainWindow:

void deployment_CheckForUpdateCompleted(object sender, CheckForUpdateCompletedEventArgs e)
{
   ClickOnceUpdateAvailable = e.UpdateAvailable;
   if (ClickOnceUpdateAvailable)
   {
      foreach (MainWindow m in this.windows)
      {
         m.UpdateAvailableLabel.Visibility = Visibility.Visible;
      }
   }
}

The label is really simple, just a label with a glow:

<TextBlock x:Name="UpdateAvailableLabel" Visibility="Collapsed" Margin="15,0,0,0" FontSize="12">
   <TextBlock.BitmapEffect>
      <BitmapEffectGroup>
         <OuterGlowBitmapEffect x:Name="UpdateGlow" GlowColor="Red" GlowSize="3"/>
      </BitmapEffectGroup>
   </TextBlock.BitmapEffect>
   <Bold>Update Available - Visit Options to Update BabySmash!</Bold>
</TextBlock>

Except the glow "pulses" between three colors and repeats forever. I set the DesiredFrameRate to a low number like 10 fps rather than what WPF will attempt, which is 60 fps! I'll post later how we can detect how awesome the user's hardware is and scale or turn off animations and effects.

<Window.Resources>
    <Storyboard x:Key="Timeline1" Timeline.DesiredFrameRate="10">
        <ColorAnimationUsingKeyFrames BeginTime="00:00:00" RepeatBehavior="Forever" 
                                      AutoReverse="True" Storyboard.TargetName="UpdateGlow" 
                                      Storyboard.TargetProperty="GlowColor" >
            <SplineColorKeyFrame Value="#FFCDCDCD" KeyTime="00:00:00"/>
            <SplineColorKeyFrame Value="#FFB92121" KeyTime="00:00:01"/>
            <SplineColorKeyFrame Value="#FF2921B9" KeyTime="00:00:02"/>
        </ColorAnimationUsingKeyFrames>
    </Storyboard>
</Window.Resources>

<Window.Triggers>
    <EventTrigger RoutedEvent="FrameworkElement.Loaded">
        <BeginStoryboard Storyboard="{StaticResource Timeline1}"/>
    </EventTrigger>
    <EventTrigger RoutedEvent="FrameworkElement.Loaded"/>
</Window.Triggers>

Now I've got a nice passive FYI that there's an update.

I want to show an update button when the user visits the Options Dialog, which brings me to my awesome volunteer designer Felix Corke (blog). If you want a great WPF or XAML designer, give Felix money. Here's my original Option Dialog:

And here's the Felix version:

Seriously. It hurts. Brings a tear to my eye.

When the user needs to update, I'll do two things. First, there will be a button that says UPDATE!

Second, after they've hit Update there will be a Progress Bar and that will update as the new version is download in the background.

The API is surprisingly easy to use. We check to see if we were launched from the Network, then I check again (really not needed since I did it earlier, but I like to double-check) for an update. This isn't asynchronous, but it's fast.

I setup two event handlers to listen to the UpdateProgress changing, and to get notification when the system has completed the download of the update. Then I fire off an asynchronous update. 

private void updateButton_Click(object sender, RoutedEventArgs e)
{
   if (ApplicationDeployment.IsNetworkDeployed)
   {
      ApplicationDeployment deployment = ApplicationDeployment.CurrentDeployment;
      if (deployment.CheckForUpdate())
      {
         MessageBoxResult res = MessageBox.Show("A new version of the application is available, 
                                do you want to update? This will likely take a few minutes...",
            "BabySmash Updater",  MessageBoxButton.YesNo);
         if (res == MessageBoxResult.Yes)
         {
            try
            {
               deployment.UpdateProgressChanged += deployment_UpdateProgressChanged;
               deployment.UpdateCompleted += deployment_UpdateCompleted;
               deployment.UpdateAsync();
            }
            catch (Exception)
            {
               MessageBox.Show("Sorry, but an error has occurred while updating. 
                   Please try again or contact us a http://feedback.babysmash.com. We're still learning!",
                  "BabySmash Updater", MessageBoxButton.OK);
            }
         }
      }
      else
      {
         MessageBox.Show("No updates available.", "BabySmash Updater");
      }
   }
   else
   {
      MessageBox.Show("Updates not allowed unless you are launched through ClickOnce from http://www.babysmash.com!");
   }
}

The ProgressChanged event is really convenient because it includes the percentage complete! One less thing for me to do.

void deployment_UpdateProgressChanged(object sender, DeploymentProgressChangedEventArgs e)
{
   this.updateProgress.Value = e.ProgressPercentage;
}

The Completed event is also fairly tidy (this one is simplified, and you could always use extra error handling. Note that since this was an asynchronous call, any exceptions that might have occurred elsewhere will show up here in the Error property of the AsyncCompletedEventArgs parameter.

void deployment_UpdateCompleted(object sender, System.ComponentModel.AsyncCompletedEventArgs e)
{
   MessageBoxResult res2 = MessageBoxResult.None;
   if (e.Error == null)
   {
      res2 = MessageBox.Show("Update complete, do you want to restart the application to apply the update?",
         "Application Updater", MessageBoxButton.YesNo);
   }
   else
   {
      MessageBox.Show("Sorry, but an error has occured while updating. Please try again or contact us a http://feedback.babysmash.com. We're still learning!",
         "Application Updater", MessageBoxButton.OK);
   }
   if (res2 == MessageBoxResult.Yes)
   {
      System.Windows.Forms.Application.Restart();
   }
}

I'll update this app to .NET 3.5 SP1 when it ships and I'll get a bunch of new features to make BabySmash! better like:

• Smaller Client Profile for machines without .NET on them. From like 75megs down to like 25megs with a 200k bookstrapper.
• Firefox Support for ClickOnce.
• Faster startup.
• More hardware accelerated effects in WPF.

All in all, not much code for me to switch from an automatic ClickOnce Deployment that I had no control over to one I now have not only complete control over, but also one that fits in more nicely with our always improving UI. Also, an FYI, ClickOnce works with WinForms or WPF equally.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By