In part 1 I explained how to write and implement a self updating windows program. The functionality was simple. Just before I close the program to be updated, I open the “update.bat“ file. Then I close the program. The bat file first pings to create a delay and after the ping it copies the new files to the directory. When its finished it will open the application again.
Because the interaction with the user is not so great, although I did not receive any complaints, I decided to improve this part of the application.
After some thinking I came up with the idea to create an updater program which can be used for multiple programs. So it had to be configurable.
The only thing you have to do is to copy the updater.exe and its configuration file to your solution. Make sure it is copied to the bin folder. Just add it to your solution and right-click on the files and choose properties. Then you will see the property copy to output directory. Set this property to: Copy always. Then you fill in the path in the configuration file. The configuration file could look something like this:
<?xml version="1.0" encoding="utf-8" ?>
<add key="UpdateFilesPath" value="\\fileserver\updates\myprogram\latestversion\"/>
Then in the directory where the new files are placed, you’ll have to add an XML file called:updateInfo.xml with the following format:
<?xml version="1.0" standalone="yes"?>
<ExtraInfo>Test version for update</ExtraInfo>
So here we can set the parameters of the updater. The new version and extra info parameters are simply to inform the user during update about what is being updated. The application name is shown on the tool as well, but is also used to check if the program to be updated is still in use. So it is important this is exactly the same is the exe you are trying to update.
The delete previous version (DeletePrevVersion) parameter is like it suggests: deleting all the files of the previous version.
To check if a new version is needed and to start the updater is similar as in part 1, but I will explain it again:
Because I’m working on a network with a database, I’ll check the database for a new version:
Assembly asm = Assembly.GetExecutingAssembly();
//Check registration and version
If there is a newer version then the current version of the program I will start an update:
System.Diagnostics.Process.Start(Application.StartupPath + @"\Updater.exe");
After I started the updater program, I’ll write some information to the database and close the application. The updater will wait until the program is closed until it starts the update.
This check is performed like this:
bool into = false;
string updatePath = ConfigurationSettings.AppSettings["UpdateFilesPath"];
int counter = 0;
File.Copy(updatePath + @"\" + appName + ".exe", appName + ".exe", true);
into = true;
if (counter > 10)
The deletion an copying of the files are done in a seperate thread, so it doesn't interfear with the GUI. The progress is set with thread safe methods. Before the update starts, I count the number of files to be copied and use this to set the progress bar limit. So it will give you a windows like information, if there is a files in the upload that is much bigger then the rest, the progress will not be as accurate. But still it give a better view then nothing, or just a wiating arrow.
When the copy is successful the program will go on to copy all files and if requested first delete all old files. The only files that are not deleted and copied over are the files of the updater itself. So it is really important that your updater is working really good and tested through several times. The update files have to be on the network, I'm currently working on an update of this program that enables you to place the update files on the internet. Then I should rewrite the File.Copy part.
That’s why I look at the updater not as a part of any solution but a separate program that can be used throughout all kinds of windows applications.