To replicate this update behavior you need two things:
-
An updater application which checks for updates regularly. If an update is found it should install it automatically. Most commercial setup authoring tools include good updater applications. You can try writing an updater yourself, but it’s not as easy as it sounds.
-
Per-user installations for each of your product versions. A per-user installation writes data only in the user profile folder (AppData, Roaming folder etc.) and HKEY_CURRENT_USER. No Program Files or HKEY_LOCAL_MACHINE.
Per-user installations are required so you can perform the upgrade silently. If the installation is per machine, newer Windows version will show the elevation prompt and the user won’t know what’s happening.
The Updater
Some updaters use services. For automated updates this isn’t a real solution because service installation needs Administrator privileges. So your install process and subsequent updates would show elevation prompts.
Another approach is to use a per-user Updater application. It doesn’t require any elevation and it can be installed in the application folder. This type of updater can run either as a scheduled task or from within your application (execute it when your application starts).
In both scenarios you need to consider that the Updater may need to update itself. So the process which performs the update must be a temporary process (for example a temporary copy of the updater application). It also should run without elevation. This is why a service is not such a good idea. It would need to stop itself before the update, use a temporary process which handles the update and start again when finished.
Other things to consider are:
- permissions issues (if the update process needs any privileges or elevation)
- download locations
- update detection mechanism (how the Updater detects if a new version should be installed or not)
The updates
A common misconception is that updates should be the application files (like the main application EXE). This is rarely the case because an update may need to overwrite more than just a file.
Most updates are installation packages (MSI for example) or patches (MSP). This is the best approach because they handle the entire update logic:
- detect running applications
- update resources
- update the product information (shortcuts, Programs and Features applet in Control Panel etc.)
Installation packages also simplify the Updater application. With this type of updates the Updater needs only to detect available updates, download them and execute them.
Updates works in two ways:
- major upgrades: the old version is completely uninstalled before the new one is installed
- minor upgrades: the old version is patched
Windows Installer has great support for both of them, so you could use MSI packages and MSP patches. It also supports silent installations, so all your Updater needs to do is execute the package with a command line parameter.
These packages also support per-user or per-machine installations through ALLUSERS property.
Update distribution
After you decide on an Updater and some update packages, you also need a distribution mechanism:
- a way to inform the updater that updates are available (for example an updates information file on your server)
- a way to detect if an update is installed or not (so it’s installed only once)
All of this is not very easy. This is why a lot of products use third-party Updaters. Even some commercial setup authoring tools offer Updaters for your packages.
A custom updater is mostly used by very large companies with a lot of products, because the investment is worth it for them.