How to implement an automatic update detection model

Question

Our software is not ever officially installed on Windows, and currently has an update model like this:

1. Connect to Internet

2. Click an Update Button

3. Connect to server-side program

4. Server-side program creates an md5 hash list of all the files in the server program directory.

5. Client-side program creates an md5 hash list of all the files in the client program directory.

6. A comparison is done to see if a file needs updated, removed from, or added to the client's machine, and it does so until complete.

Well, I would like to move to a model I see used more frequently these days where the software is officially installed and something like this happens:

1. When an internet connection is detected, the program will automatically query the server to see if there is an updated installation package.

2. If so, ask the user if they would like to download the new install.

3. If no, do nothing, if yes, download new install.

4. Programatically uninstall the old program and start the install of the new package.

The part I need advice on is number 4 above. What is the best way to programmatically uninstall the old program and start the installation of the new program, while running the original program. I assume there must be some intermediary program that does all the work (shutting down the current program, running it's uninstaller, then starting up the new installer) Is there a better way? I just want to move to a model where we update in full installs and not just files - this will allow us to version our software easier and keep self-contained installations to revert to at any point.

Thanks for your advice!

EDIT: Related question - what's the easiest way to find the install UUID for a particular install?

Answer 1

The way I did it was to have a separate program (let's call it StartUp.exe) that checked for updates and then loaded the real software (let's call that Program.exe). StartUp.exe had the same icon as Program.exe and was the executable that was pointed to by the desktop shortcuts and menu items, using the same name as Program.exe.

So the sequence went something like this:

1. User double-clicks desktop shortcut or menu item that looks like Program.exe and is called the same name but is actually StartUp.exe
2. StartUp.exe runs and checks if there are any updates
3. If there are updates, it simply copies then across (we built a nice system with progress bars but you could simply copy the new files over the old files)
4. StartUp.exe then runs Program.exe
5. StartUp.exe then exits

This has the advantage that none of your program files are locked because the loader program is actually a different program. The user is none the wiser because they run a program that looks like and is called the same as the program they want to run and the end result is the program they want does run and is guaranteed to be the most up to date version.

Doing it with an update button would be more complex but we needed to force the most recent version of the program to be the one running (due to database differences between versions) so forcing update on startup worked for us.

I believe the way to do it these days is to use ClickOnce deployment but I've never tried that - it wasn't available when I wrote my system and this method was simple and worked well.