[ACCEPTED]-Delphi: How do you auto-update your applications?-auto-update

What ever scheme you use, it may be handy 8 to know that you can actually rename a running 7 .exe file. So rename file, copy in new file 6 works nice. And the next time someone launch 5 the program they will launch a the new version. This 4 is ofcourse very handy in enviroment where 3 many users run the same .exe file, like 2 in citrix/terminal server/network share 1 cases.

Years ago I wrote a simple tool which is 27 started instead of the real program, checks 26 for updates, loads and installs them (if 25 any are available), and finally starts the 24 real application.

There are however problems 23 with that approach if your program works 22 in a properly administered environment, where 21 users normally don't have write access to 20 the program directories. You can no longer 19 simply update your own program in such environments. That's 18 why a lot of programs these days come with 17 their own updater tool, which can be installed 16 to run with elevated permissions, so that 15 program updates can be applied even though 14 only standard users do ever log on to the 13 system.

You have to decide whether your target 12 audience can be assumed to run on power 11 user or administrator accounts, or whether 10 you will have to deal with above-mentioned 9 problems. With Vista things got considerably 8 harder already.

With all these problems (net 7 access over proxies, missing write permissions 6 for installation directories, the need to 5 update files that the updater itself is 4 using - just to name a few) I wouldn't try 3 again to code this on my own. Much better 2 to check if any one of the available solutions 1 does all you need it to.

I use the Synapse routines GetHTTP to return a 28 specific resource, and if found then check 27 against the local system to see if an update 26 is required. If so then the resource tells 25 me what page to go to launch and I throw 24 the URL into shell execute so the users 23 preferred browser is displayed.

Most of 22 the time the download is a setup program 21 created by InnoSetup which updates the users 20 system and database to the latest version. When 19 a new "paid" upgrade is needed, I 18 then send the user to a "purchase upgrade" form. My 17 web resources are ASP pages, so I can redirect 16 to a different resource based on the customers 15 version number.

For the main application 14 (our application has a server piece, and 13 a client piece) I have a loader which will 12 check the server to see if the version of 11 the client file on the server is different 10 than the version on the client...if so, it 9 prompts the user if the user wants to update/revert. We 8 chose to prompt the user as sometimes an 7 accidental bug might make it into the system 6 and the user has to downgrade/upgrade only 5 specific machines to help troubleshoot. I 4 maintain a database record with the minimum 3 version required which is updated via the 2 database patch, so if a version must be 1 retired then the record is updated accordingly.

I created my own solution too based on Indy 4 for downloading and http://sourceforge.net/projects/makeupdate/ for file patching. Before 3 that I have used and tried several commercial 2 tools, but no one was doing exactly what 1 I needed.

I use TmxWebUpdate. It's free, simple and gives you 4 good control over the process. I actually 3 own TMS Component Pack with TWebUpdate but 2 never really found a good reason to switch.

Edit: Link 1 updated

We rolled our own as well. Its really not 20 too difficult.

Our process goes something 19 like:

• When the main app is launched, it checks 18 (using funcs from the synapse library) if 17 there's an update available (assuming its 16 configured to check, of course).

• If so, it 15 notifies the user and askes if they want 14 to update.

• If they do, it launches an updater 13 .exe, and closes the main app.

• The updater 12 exe downloads the new files based on the 11 contents of a text file it retrieves, keepiing 10 the files in memory.

• When the updater is done downloading 9 everything correctly, it then saves the 8 downloaded files to disk, backing up any 7 files it replaces. This way if the download 6 gets interupted, you dont end up with half 5 the files installed.

• Finally, it launches 4 the main app again, and closes itself.

The 3 trick w/ Vista is that you need to have 2 an entry in the updater program's manifest 1 to force it to run with administrator rights.

Normally we use the third party tool. But 3 in some situations it was not usable so 2 I created an own solution, which was pretty 1 standard:

• Get xml (or any other format) with update info.
• If newer files are published, download and install them.

I use TWebUpdate . It works ok and has a ton of interesting 5 options, but documentation isn't so great 4 and I did bump into a few problems - which 3 is why I download a full installer, instead 2 of just the files...

I will be keeping an 1 eye on this question, btw...

We use our own solution which follows these 22 steps:

1. Application connects to http resource and downloads info file (ini text file) to memory, checks version number of newest release.
2. If newer version available, app downloads compressed binary package to exe location.
3. When download is finished, user is asked to restart application.
4. Upon start, application checks for presence of update package
5. App extracts package contents (usually a new app exe, but additional resources possible as well, e.g. updated language files etc.) - for each file it renames the current/old file to a temp name first, then extracts the new file. If the process fails at any point, the temp files are restored.
6. When finished, app executes new exe and closes itself.

No additional updater needed, the 21 app exe can handle it all by itself.

For 20 the compressed package we use our own update 19 builder. The package contains an index of 18 files with a file hash, destination folder 17 (relative path to main exe) and the compressed 16 files. During update we compare the stored 15 hash with the extracted file to detect corupted 14 files.

With Vista I see two solutions to 13 enable Standard User Accounts to actually 12 update the applications files:

1. Configure 11 your setup to change permissions of the 10 programs installation directory. This way 9 files in "C:\Program Files (x86)\Your Company\You 8 App" can be modified on Accounts with limited 7 rights.

   Example code for InnoSetup would 6 be:

   [Dirs]
   Name: "{app}"; Permissions: users-modify
   

2. Install files that you plan to update 5 to the ProgramData folder instead of the 4 user defined directory and use this directory 3 as an override folder. If files exist in 2 ProgramData, use those, else check in install 1 dir.

   InnoSetup code:

   [Files]
   Source: "C:\Your Project\YourApp.exe"; DestDir: "{commonappdata}\Company Name\App Name\"; 
   

Same as "stg" and "GuyWithDogs", I'm using 11 TWebUpdate from TMS. Although the documentation 10 isn't so great, Its not so difficult to 9 learnt.

With TWebUpdate, you have some options 8 what the protocol you use, it could be done 7 via HTTP, FTP or network access.

For communication 6 layer, TWebUpdate uses WinInet. In some 5 machines, the windows / IE URL cache can 4 be frustating, so I've added a routine to 3 clear the auto-update server address from 2 cache first to ensure the information gathered 1 from the server is up-to-date.