Best method for implementing Self-Updating Software

Question

We have a minimal 'updater' exe that checks a remote URL for updates, downloads them and replaces files on disk prior to launching the real application. However if we want to replace the updater EXE then AFAIK we have two options:

1. Shadow Copying Assemblies whereby .Net will create a shadow copy of the EXE (and any referenced assemblies) and load those assemblies, such that the non-shadow assemblies can be replaced and will be used when the application is next launched.

2. Identify which files are replaced and rename/move them on disk. Windows seems to allow the renaming/moving of locked files, so we can move the files and copy in the new assemblies. Again, on next launching the application we will be launching the new assemblies. This approach is mentioned here

Is this second method a recommended method? Are there any pitfalls to this approach?

Demon

Answer 1

What about ClickOnce deployment?

Commercialism

This is probably the best option as it should help standardize the security level upgrade/downgrading that is required in windows Vista and future versions of windows – Brickyard

We aren't using ClickOnce for now as it was easier to use the file copying method I described, and we also have a cutomised update process for an SQL database that gets installed alongside the application. However ClickOnce is the official Microsoft solution and one we will look into more with an eye for future use, therefore I'm choosing this as the accepted answer. Thanks. – Demon

ClickOnce is a nightmare because it is inflexible, overly complex, appears to have no strong Microsoft support, and is very specific to per user deployment scenarios. – Macaroni

Answer 2

Another option: when the main application wants to update itself, it spawns a new updater process and then closes itself. The spawned process in the meantime waits for the main application to close (the process to disappear) and then updates all of the necessary files (including the .exe). After that it simply restarts the main application and exits the updater process.

Disseminate

@jpierson and it works :). I've been using this approach for 2 years now for my own application. – Disseminate

Not following what "spawns" means here. Surely the spawned process still references the same .exe and other library files, which therefore cannot be overwritten? – Disendow

@Disendow no, in my case the spawned process is run from a separate .exe that does not reference the main .exe nor any of the library files. – Disseminate

Answer 3

Im using the second method without any problems. Just make sure the downloaded assembly was correctly downloaded. ;)

Run Update.exe and let it do this:

1. download the new update.exe as update.ex_
2. rename the update.exe to update.bak (you can rename it, but not overwrite it)
3. rename the update.ex_ to update.exe
4. restart update.exe

Im doing this with no problems at all so its tested and are running in live environment in about 400 customers as we speak.

Ene

how would I restart the currently running program? is there an easy way? – Comstock

@chilitom : process.start (Application.StartupPath & "\myprogram.exe") :end – Ene

Answer 4

In a project i worked on, there where 2 executables. Let's call them A and B.

The only reason A existed was to start B. So, when B (the 'real' application) downloaded an update, it was able to replace A if neccesary.

If the application was restarted (via A), A checked if B downloaded some files and replaced them before it started B.

Verbal

Recently I stumbled across the fact that a running executable cannot be overwritten but it can be renamed. I've tried this out myself in a test app and I'll be using this technique to develop my own application self updater component. – Macaroni

Have a look into Shadow Copying (msdn.microsoft.com/en-us/library/ms404279.aspx). We use it to allow clients on a terminal server to update the client software while other users are running the application on the same machine at the same time. – Verbal

Answer 5

The way we do it with our in-house app:

The application shortcut points to the updater.

1. Downtime notifications/deadline messages are displayed.
2. the updater performs an update check.
3. Updates are downloaded and installed.
4. Application is launched.
5. Application performs update of the updater (checks for Updater.fp7.gz in the /update folder)

Edit: Oops - missed step 5.

Burble

You did read the question right? How do you update the updater itself in your scenario? – Grout

Answer 6

I mostly agree with Stefan's Answer except for that it may not work if you want to properly deal with UAC on Windows Vista or Windows 7 and your app is properly installed under the Program Files folder or requires other dependencies to be installed that need elevated permissions.

In this case you are either doing an msi based install/patch or installing a Windows Service that runs with the necessary security to overwrite files in the Program Files folder.

The other option if your app is interactive is to do as Igor Brejc suggests and spawn a new process that does the updating which gives your app a chance to prompt to elevate permissions during the update. Using the patch or Windows Service option as mentioned above though would give a better user experience regardless of the scenario (interactive/non-interactive).

Macaroni