Silverlight makes updating your out-of-browser XAP a breeze. It does the heavy lifting for you, asking that you merely invoke the update logic from within your app at a time or frequency of your choosing, and respond to events raised by Silverlight.
If an updated XAP has been published to your web server, Silverlight will download and induct it to the offline application cache. The next time your app is activated, Silverlight will ensure the updated bits are activated and the old bits are scavenged.
What the app author needs to do
Employ the async-pattern APIs exposed for updates in your out-of-browser apps. The trigger method is the Application.CheckAndDownloadUpdateAsync() method. Hook up an event handler for the CheckAndDownloadUpdateCompleted event. See, there’s not much to it! No messing with version numbers or the like.
Gotchas?
Well the only thing to watch out for is the situation when a new version of Silverlight comes out (say v4) and your app is built against it, but the consumer is running an older runtime (say, v3) and an appropriate older version of your app. In this situation, the app update cannot be applied because it requires a runtime update first. Silverlight notifies your app of this situation by setting the event arg’s Error property value to System.PlatformNotSupportedException.
All in all, here’s the code you’re going to write:
private void SomeMethod()
{
Application.Current.CheckAndDownloadUpdateAsync();
}
private void App_CheckAndDownloadUpdateCompleted(object sender,
CheckAndDownloadUpdateCompletedEventArgs e)
{
if (e.UpdateAvailable)
{
MessageBox.Show("An update has been downloaded. " +
"Restart the application to run the new version.");
}
else if (e.Error != null &&
e.Error is PlatformNotSupportedException)
{
MessageBox.Show("An application update is available, " +
"but it requires a new version of Silverlight. " +
"Visit the application home page to upgrade.");
}
else
{
MessageBox.Show("There is no update available.");
}
}
What the app publisher needs to do
If you handle application deployments or administer web servers, all you need to do is xcopy the new XAP (plus any external content files it needs) in place of the old XAP. Silverlight will take it from there.
In the end, a word to the wise... Make sure you clearly articulate your app's update policy to your end users. Whether you auto-update, or require user-initiation; whether you update upon every app launch or at another discrete frequency; let your app's consumer audience know. Ideally you'd grant them the ability to override your defaults. This is the right thing to do. The user must always be in control.
Previous posts in this series:
Read: Silverlight out-of-browser apps: How Updates Work
