1

I have an application (WinForms C#) in which I would like to copy some files from a "Downloads" directory into the ProgramFiles directory. Essentially I am trying to update some (or all) of the currently running program dlls and executables by rolling my own automatic updater.

So I have the application automatically checking for updates and downloading updates into the ProgramData\MyApplication directory. The problem is, I need to overwrite all the files for the application in its corresponding ProgramFiles\MyApplication directory, including the .exe which is currently running. Any idea on how this could be performed?

Chadley08
  • 559
  • 1
  • 8
  • 26
  • Here is a solution for your problem.Check it out [solution][1]. [1]: http://stackoverflow.com/questions/2335755/how-to-update-an-assembly-for-a-running-c-sharp-process-aka-hot-deploy – Abolfazl Hosnoddin Apr 16 '14 at 21:53
  • Interesting, I was thinking of starting the process using Process.Start("PathToMyUpdaterExecutable") and then calling Application.Exit() from the main program...do you think that is a good approach? – Chadley08 Apr 16 '14 at 22:00
  • I suggested you that way, because you was looking for self-updating. Better idea will be to use Standard approach such as martin_costello Answered you below. – Abolfazl Hosnoddin Apr 16 '14 at 22:04

1 Answers1

2

Writing a self-updating application correctly is not a trivial task. Most of the problems you mention in your question, such as files in use etc.

From trial and error I find that the best approach (roughly) is to:

  1. Create a system-wide event in the application using wait handles that can listen for requests to shutdown from another process.
  2. Package the application via an MSI installer.
  3. Use a bootstrap application in %TEMP% folder to send the signal to the first application, and start the MSI installer.
  4. The MSI will then handle all the other hard work of actually updating the application for you, dealing with file locks etc.

Unfortunately, the problem with self-updating apps is that unless you design all of this to work with v1 (and test it before release with a fake v1.1), then you'll find that you need features in the old version to help do the update to the new version.

If an MSI installer isn't an option, then a bootstrap application running in a temporary directory that can do the swapping, process termination etc. is a good way to start.

Depending on your application design, you may also need to ensure that the self-update process elevates itself on Windows Vista and later so that it can write to directories such as %PROGRAMFILES% to do the file writes.

Martin Costello
  • 9,672
  • 5
  • 60
  • 72
  • My first idea was to have a separate application deployed with the software which gets run from the original application (using Process.Start()) and copy/pastes the relevant dlls and exe's to the program files folder. I think that is what you are saying here "If an MSI installer isn't an option, then a bootstrap application running in a temporary directory that can do the swapping, process termination etc. is a good way to start." So I am going to give that a try. Thanks! – Chadley08 Apr 16 '14 at 22:08
  • No problem. Just to mention, I did start with an application that updated the other directly, but it had a number of reliability issues that lead me to change it to just be a bootstrapper to run the MSI installer. It depends on your installation footprint. The application I was working on had a lot of files, and also a configuration file to deal with that sometimes also required schema migration between versions. – Martin Costello Apr 16 '14 at 22:12
  • Good to know. We are going to start with a simple implementation of the updater (just replacing the dll's and exe's) and we might expand it from there. I'll keep this in mind as we move forward and look into how to implement the bootstrapper + MSI Installer. Thanks Again. – Chadley08 Apr 16 '14 at 22:14