So, I hear there are a lot of programs out there that check for newer versions when you run them. As an end user I find this feature annoying more often than not: how many Windows Media updates are there per week anyway? As a writer of software it is very nice to have an update feature built into anything you wish to distribute to more than 2 people. There is a nice Updater Application Block, extensible and easy, and I think there are some partial ports to the compact framework or MSDN CAB-downloader examples out there. From what I've seen these either don't suit my needs or would require some serious shoe-horning to make them fit my needs. One of my favorite clients, with their non-Microsoft backend systems now needs Updater functionality, so I set out to design something flexible.
- There is a custom sync process that runs while the system is connected, so I want to query a backend system for what updates might be available for the unit
- I want to be able to download CAB files containing new versions of the main system (of course)
- Download arbitrary files for that matter
- I want to be able to Execute these CABs, and any other arbitrary shell executable
- I want to be able to modify the local databases, they are huge so just rebuilding is not an option
- I want to be able to have the unit upload arbitrary files
The reasons for these should be apparent but I'll explain anyway. Suppose you have a change you need to make to a system that 100 people in the field are using:
- A new user enterable field is added to a table
- New software is needed to collect this data
- You need to alter the local data sources to contain this field
Based on this idea and others, I came up with a list of "Action types" I might want to do during an update. I query the server for a list of updates passing things like the serial number of the device, and the server returns a list of these Actions sorted by order of execution. Each action has its own attributes and method of execution so the updater program can kill the main application and polymorphicly go about doing what it needs to do with things like DownloadAction, SqlAction, ShellExAction, UploadAction.
Obviously there is some work to be done on the server, essentially this will be a webservice that returns a message with the ordered set of Actions in it. This is more work than a file-based solution but also gives us the flexibility of being able to configure different updates for different devices. You probably don't want too many different versions of your software running, but the actions can be used to assist technically challenged users with deleting temp files, distribute customer-specific content, delete troublesome SqlCE data, etc. Due to various other aspects of our software its easy to set up a nag feature where the user can choose to skip the update a certain # of times and other useful stuff. The upload actions can be either FTP or HTTP PUT.
Since I mentioned it, I'll have to post about custom data synchronization processes in the future as well, since I think I've got a pretty good one and as one respected member of the Compact Framework newsgroups says "It is not trivial to go that route". Sometimes Merge Replication just makes you want to shove salt-covered icepicks through your intestines though, and I think a lot of people would use a custom sync processes if there was a proven one out there.