How should I implement auto-update?

Many programs include auto-update, where the program sometimes looks for online updates, and then downloads and applies all found updates. Program errors are fixed, support files are changed, and things (as a rule) are improved.

Unfortunately, no matter how I look, I cannot find information about this process anywhere. It seems that the automatic updates that were implemented were either proprietary or were not considered important.

It seems pretty easy to implement a system that looks for updates on the network and downloads them, if available. This part of auto-update will change significantly from implementation to implementation. The question is what are the different approaches for applying patches. Just upload the files and replace the old ones with new ones by executing the downloaded script migration, neutralizing parts of the system, etc.? Preferences are preferred, but examples in Java, C, Python, Ruby, Lisp, etc. Will be appreciated.

+54
auto-update
Oct 24 '08 at 2:59
source share
15 answers

I think that “language agnostic” will be the limiting factor here. Applications come in so many shapes and sizes that there is no answer to one size. I implemented several automatic updates in several languages, and none of them looked alike.

The most common philosophy is that the application checks with some home location (web address, web request, corporate network location, etc.) to ask if this version is current, or ask which latest version . If the response triggers an update, this process will be different for each situation.

A popular alternative is to invite the home location to run the script when the application starts. The script can check the version, download updates if necessary, and request usage feedback, for example.

Perhaps we can better help if you limit your options.

UPDATE. The “fix” approach also depends on the nature of the application, and there is a very wide variety. For example, if you have one executable, then probably the most practical is to replace the executable. If your application has a lot of files, you should look for ways to minimize the number of replaced files. If your application is customized or parameterized, you should strive to minimize reinstallation efforts. If your application uses interpreted code (for example, Excel VBA or MS Access MDB), you can replace parts of the code. In a Java application, you may need to replace the JAR file, or even a subset of the contents of the JAR. You will also need to find out the current version of the client and update it accordingly. I could go on and on, but I hope you see my point of view on diversity. This is one of those cases where the best answer usually starts with "Well, it depends ...!" This is why so many answers include "Please narrow your options."

+44
Oct. 24 '08 at 3:12
source share

Be sure to also consider the security implications when sucking update information, as well as the update files themselves.

Do you trust the download source? You may have called home to get your update, but what if there is a person in the middle who redirects to a malicious server. HTTPS or a similar secure connection will help, but it is recommended that you double-check the bit that you end up downloading with a digital signature check.

+18
Jan 28 '09 at 6:45
source share

First you need a file on your app’s home website with the latest version. The best way, in my opinion, is to create a special SQL table for this task and automatically fill it after the publication of a new version / completion of the assembly at night. Your application creates a new thread that requests an inline http link with the version and compares it with the current one. In .NET, usage can use code like this:

Version GetLatestVersion() { HttpWebRequestrequest = (HttpWebRequest)WebRequest.Create(new Uri(new Uri(http://example.net), "version.txt)); HttpWebResponse response = (HttpWebResponse)request.GetResponse(); if (request.HaveResponse) { StreamReader stream = new StreamReader(response.GetResponseStream(), Encoding.Default); return new Version(stream.ReadLine()); } else { return null; } } Version latest = GetLatestVersion(); Version current = new Version(Application.ProductVersion); if (current < latest) { // you need an update } else { // you are up-to-date } 

In this example, version.php is used in only one simple line, for example 1.0.1.0.

Another tip I can give is how to download the update. I really like the following idea: in the resources of your application there is a line of CLR code that you compile on the fly (using CodeDom) into a temporary folder, the main application calls it and closes it. Updater reads arguments, settings, or the registry and loads new modules. And it calls the main application, which deletes all temporary files. Done!

(But everything here is about .NET)

+8
Dec 04 '08 at 6:41
source share

The simplest solutions (used by many programs) are to start the uninstaller for the previous version and run the installer for the new one (not necessarily skipping questions that the user has already answered, for example EULA). The only catch is that the new version should be able to read configuration parameters from the old version.

Also, on Windows, you cannot delete the executable that is being used, so you probably want to delete the small executable in the Temp folder that starts the whole process and then removes it at the end from the instance of the new version that was running (or just register it for deletion at the next reboot ).

+5
Jan 28 '09 at 7:51
source share

The easiest approach is for your program to request a server (website) to see if there is an update. If there is an update, you can display a message to the user who will offer them to download a newer version and provide a link.

An alternative and more complex solution would be to create a small Windows service (or unix daemon) that periodically checks to see if there are updates, this service can download the update and run the installer.

The general architecture is that you have a central server that you manage, that knows the latest version and where to get it. Then the programs request the server. I will not include sample code, because it is very defendable on the server and the format you selected. This is not terribly difficult.

+2
Oct 24 '08 at 3:14
source share

This is not so much a complete answer as one example of an automatic update mechanism that I implemented recently. The situation is slightly different from a traditional user application such as Firefox, as it was an internal tool used at work.

Basically, this is a little script that manages the Subversion branch queue to be created and packaged into the installer. It reads a small file in which the names of the branches are written, takes the first one, overwrites it at the end of the file, and starts the build process, which includes calling a bunch of scripts. The configuration for each branch for the assembly is written to the .INI file stored in the Subversion repository along with the tool itself.

Since this tool works on several computers, I wanted it to automatically update it on all computers as soon as I made changes to either the tool itself or the configuration scripts.

The way I implemented it was simple: when I run the tool, it becomes an “outer shell”. This outer shell does two very simple things:

  • svn update for yourself and for configuration files
  • starts up again, this time as an “inner shell”, one that actually processes one configuration (and then exits again).

This very simple update-myself-in-a-loop system has worked well for several months. It is very elegant because it is self-sufficient: auto-update is the program itself. Since the “outer shell” (part of the automatic update) is so simple, it doesn't matter that it does not benefit from updates such as the “inner shell” (which runs from the updated source file every time).

+2
Jan 28 '09 at 7:46
source share

One thing that was not actually mentioned is that you should seriously consider that the user running your program may not have sufficient privileges to update it. This should be fairly common, at least for business users, perhaps for home users.

I always work with a limited limited account for security reasons, and it always pissed me off that most auto-updaters just assume that I work as an administrator, and then after downloading just fails and does not offer any other way to perform an update other than actually closing the program and re-launching it in an administrative context. Most of them do not even cache the downloaded update and should do it again and again.

It would be much better if auto-renewal would ask you to enter administrator credentials as needed and continue with it.

+2
Jan 29 '09 at 23:53
source share

Since automatic updating is a common scenario, most languages ​​have at least one package to support this. (Listed below are some of the available packages)

One of the really nice ideas is ClickOnce for .NET, an installation program that isolates your application and installs it in a user context, so no administrator rights are required. You can customize ClickOnce in your publication to check for updates for each application.

Java has Java Web Start , which offers the same functionality for Java applets.

There are many articles on Delphi about automatic updating, Torry has a list of WebUpdate components , for example GoUpdater seems to have a very wide range of functionality.

They all use the website / network share to check the new version and get either the patch or the full installation file and run it. Therefore, you should try to find a good package for your application in order to save you from the need to develop and maintain your own solution.

+1
Jan 28 '09 at 8:28
source share

In the Java-Webstart setup, a JNLP file is launched, which then launches the download of the Jar files needed to run the application. Each time webstart checks to see if there are newer versions of Jars and downloads them, replacing the locally cached ones. Using a tool called jardiff, you will only create differences for the new jars and distribute them through the server (for example, get only the update).

Pros:

  • always up to date

Minuses:

  • you need an application server (tomcat, JBoss) to distribute files
  • you need an internet connection to get the application
0
Jan 28 '09 at 7:33
source share

Reading the answer Carl Seleborgs gave me some ideas on how useful a common code repository is.

svn comes with the svnsync tool, which behaves like an svn export but keeps track of the actual version of your export.

Someone can use this system to retrieve modified files from the actual version of the user.

In reality, you will have a repository with compiled binaries, and running svnsync will only retrieve the binaries that have changed. It can also combine local changes to text configuration files with new configuration parameters.

0
Jan 28 '09 at 7:56
source share

The patch installation function for a program is basically one of the main functions of the installer. The installer software is documented in many places, but usually for each installer: there is the Microsoft Installer (with the installation of screen extensions), Ruby gems , Java.jar files , various Linux package manager ( RPM , Apt-get ) and others.

These are all complex systems that solve the problem of fixing programs in general, but for slightly different systems. To decide which is best for you, consider which of these systems best suits your application. Rolling is fine, but looking at these systems is the place to start.

0
Jan 28 '09 at 8:05
source share

You can write the internal module of your application for updating. You can write an external gadget for updating.

Also look at .NET compilation technology on-fly, it allows you to create such a gadget on the fly on demand. For example, http://fly.sf.net/

0
Jan 28 '09 at 8:56
source share

I am going to accept an answer for Windows.

This method seems to work well.

In the installer, do:
1. Create a manual launch service that starts as LocalSystem when the update stops at startup.
2. Change the permissions of the service so that all users can start the service (if all users should be able to update without administrator rights).
3. Modify the main program to check for updates at startup using a simple mechanism. If it detects an update, ask if the user wants to apply it.
4. If the user accepts the update, start the service.

If the architecture allows this, create a way to track the update when it starts.

0
Jan 30 '09 at 0:09
source share
0
Apr 28 '15 at 20:53 on
source share

If you are looking for a cross-platform software update solution, see www.updatenode.com

Some highlights:

  • free for open source projects
  • open source cross platform and client upgrade tool
  • already localized for the most important languages
  • easy to integrate and easy to handle
  • cloud management platform for defining and managing updates
  • provides additional support for displaying messages (information about new events, products, etc.).
  • the web interface is open (you can create your own client using the service)
  • a lot of usage statistics, like operating systems used, geolocation, version usage, etc.
  • Android API for mobile app updates

Just try it.

By the way, I'm part of the open source client development team. :)

-one
Mar 25 '14 at 13:06
source share



All Articles