I’ve been looking at the Silverlight Out-Of-Browser support and the easy update feature. In the current version, we’re given the method, CheckAndDownloadUpdateAsync(). This method does a lot for us but is rather limited. With an asynchronous method and no parameters, what can we expect? With a huge team in Redmond working for us and trying to meet deadlines, we get what we get. In the spirit of sharing, here’s what I see so far.
- Detect network connectivity (and sometimes it fails miserably…)
- Connect to the original authorized URL that it was installed from
- Download the new XAP file and compare the current version against the downloaded version from the manifest
- Detect the current Silverlight version vs. the new version’s Silverlight version
- If a failure occurs, failure exception types are provided for recovery such as “PlatformNotSupportedException”
- Can’t interrupted the request. So when it times out, we wait for it.
- Can’t download the update and make it optional to install and replace the currently running XAP. A flag to just detect a newer version would be better. This would allow the UI to show the current version and available update version.
- Returns a false for the “UpdateAvailable” property for several reasons such as the new XAP is not signed, is a newer Silverlight Version, or various other errors. We must then look at *ALL* of the possible error class types placed in the error collection. A bunch of try-catches are therefore necessary. The try-catches do the job as long as we have every possible error type in a catch. An enum for the actual error reason may be better.
- Can’t revert to a previous stable version and have it install over a newer bad version. It makes sense, but real development teams have recovery plans when updating production versions.
Q: What if we want to make the newer XAP file replacement optional? Here are some thoughts.
Not everyone wants to increase the newer version number for a rollback version. The Silverlight client can call the web server to get the new version number using other networking connectivity options. The server call could be as complicated as a WCF service, ASMX service, Web Method call, or an HTTPRequest to get the online version information. Getting the version from the server could be as complicated as reading the newer version’s manifest file, read the new file date and time, or newer folder date and time. It could be as simple as getting a text file that has only the expected Silverlight version and the new XAP version. If the major or minor version is different, then the Silverlight client can act appropriately such as displaying an update message box or button to perform the CheckAndDownloadUpdateAsync() call. The only issues I can imagine would be security issues of calling back to a “different” server where a ClientAccessPolicy.xml file is required. If it were HTTPS from the install, the new version check call may to an HTTP. The different server could also include “WWW” or not include it and therefore require the ClientAccessPolicy.xml file. The simple version text file can be automatically generated in the Silverlight application build script. This way DEV, QA, and Production can generate and test it easily without requiring the file to be edited every time it gets deployed. This may not allow a previous version to replace a new bad version (users install updates with the Silverlight plugin, not our code) but it does get closer so the installed version can stop working or corrupting data until they uninstall and reinstall the previous version. A rollback with a version increase is easier so we can just call CheckAndDownloadUpdateAsync for the actual rollback. Again, these are just some thoughts to get closer to real-world deployments.
A Silverlight OOB launcher debugger is available. More information: http://blogs.msdn.com/b/silverlight_sdk/archive/2010/04/10/sllauncher-error-messages.aspx
Q: Needs some good code examples? A few really good Silverlight OOB blog entries can be found here: http://nerddawg.blogspot.com/search/label/Out-of-browser
This should give some food for thought until we get a more robust CheckAndDownloadUpdateAsync method.