Google Chrome auto updates itself every five hours. I want to clone this exact functionality in my own application. What is a way to implement this functionality on Windows?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Google Chrome auto updates itself every five hours. I want to clone this exact functionality in my own application. What is a way to implement this functionality on Windows?
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:
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:
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:
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:
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.