Script/program Auto Updater

[storme]

YOUR Software updates

Most programs will need to be (read should be) updated sometime in their life.

There are many concepts of how to do updates.

Usually you have to embed the update into each program.

THEN! You have to allow ALL of these programs access to the internet through your firewall.

My Concept

How about ONE program to check/Download/replace all of your programs?

Advantages:

Allow the ONE program to access the internet for all updates.

Install the ONE program then have your other programs “register” with it. Then just run that one program to update everything.

If you change your update method you don’t have to recompile every program, just the one updater.

So that is the concept I’d like to hear everyone’s ideas good and bad.

What do you thing worth it or forget it?

Basic out line of program.

Modes (selected by Command line)

- Update ALL – Update all registered programs

- Update {Path of program} {Program path} – Update single script, kill process if updated and restart updated script

- Register {Path of program} – Register programs for updates

- Check {Path of program} – return code indicates if update required

Method

Updater program will download an INI file from a server (hard coded or maybe INI/reg) into the updater.

The INI contains “Program Name”, “Version number”, “Download path” for each program.

The program is looked up, the version checked and if necessary, the update downloaded.

The first version of the updater will simply overwrite the program and restart it if necessary.

Later versions may contain more elaborate setups if required/requested.

OK that is the BASIC outline of the program any suggestions/additions that you’d like in the program?

If there is enough interest I’ll get it written up if not I’ll hack up something simple for myself.

Thanks for any feedback!

John Morrison

Aka

Storm-E

[Rogue5099]

Pros:

1. You can update all programs with 1 .exe

2. You don't need to open each program to check for update

3. You only have to edit 1 script to change download locations

Cons:

1. Most people will only have 1 of your programs

2. Other people will have to have 2 of your programs to update

3. People might not run your updater

4. It's better to have your script check for update on load

5. Might update a program that works fine on your system and dont want to chance updating to corrupt it

Best way to do this is have have all your scripts point to a single .ini download at startup. All info will be in that .ini but the program will only search for itself in the .ini. If update is available ask user if they want to update. Since these are your scripts you should have the latest version so this is to benifit others.

Just create a .au3 put it in your Includes folder and just Include it at the top of each of your scripts. 1 line to add to each script and 1 .au3 to edit if needed. You would have to compile all your programs once you update anyways and once that is in place (all programs compiled with new .au3) then it would be a flawless update. The programs will check downloaded .ini and if update is available it would update, including updating the edited .au3 if needed!

Edited August 28, 2011 by rogue5099

[FaridAgl]

I just compiled this code as a3x and call it each time my main program run, if there is a new update message box will appear else nothing.

in the msgbox if user click on Yes download link will appear in the default web broweser, if click on no nothing.

note that if there is a new version user should just download a file about 1.5 mb so no problem if user download all files, but when the main program have more size it's better to download only necessary files and replace them.

#NoTrayIcon

$GetVersion = InetGet("http://garena.godlike-exp.ir/version.godlike", @TempDir & "\version.godlike", 1, 1)
Do
Until InetGetInfo($GetVersion, 2)
InetClose($GetVersion)

$CurrentVersion = 5.32
$LatestVersion = IniRead(@TempDir & "\version.godlike", "GoDLiKe.eXp", "Version", $CurrentVersion)
$DownloadLink = IniRead(@TempDir & "\version.godlike", "GoDLiKe.eXp", "URL", "")

FileDelete(@TempDir & "\version.godlike")

If $LatestVersion > $CurrentVersion Then

    $User = MsgBox(36, "Check for Updates" & $LatestVersion & " released.", "GoDLiKe.eXp " & $LatestVersion & " released. Do you want to download it now?")

    If $User = 6 Then
        ShellExecute($DownloadLink)
    EndIf
EndIf

[rcmaehl]

Suggestion: Use InetRead instead of InetGet

[guinness]

If you use InetRead then I would search the forum for 'IniString' as IniRead can only read a file. Another suggestion is using InetRead & _StringBetween due to some users having the inability to upload an INI file for example on wordpress blogs. How I've done it in the past is add a comment to the blog e.g. <! --<Version>1.0</Version>--> and then using _StringBetween I find the value of 1.0.

[storme]

Thanks for the feedback.

Pros:

1. You can update all programs with 1 .exe

2. You don't need to open each program to check for update

3. You only have to edit 1 script to change download locations

Yep

Cons:

1. Most people will only have 1 of your programs

2. Other people will have to have 2 of your programs to update

3. People might not run your updater

4. It's better to have your script check for update on load

5. Might update a program that works fine on your system and don’t want to chance updating to corrupt it

1. In my case "no" they will have more than one. But having one or 2 isn't that big a problem.

2. I'm guessing you mean the main program and the updater. Not really an issue as the user doesn't need to do anything to update them. Except run the script or run the updater in UPDATE-ALL mode.

3. They don't need to as the updater will/can be called by the script.

(Command line -Update {Path of program} {Program path} – Update single script, kill process if updated and restart updated script)

4. Yep the main script can call the updater to check if it needs to be updated OR just call the updater to update the script.

5. But this is the problem no matter what method is used to do updates. It really comes down to A MAYBE problem if it updates or a guaranteed problem with an out of date script.

Best way to do this is have have all your scripts point to a single .ini download at startup. All info will be in that .ini but the program will only search for itself in the .ini. If update is available ask user if they want to update. Since these are your scripts you should have the latest version so this is to benifit others.

Basically you've described what the updater will do except it's external to the main script.

The need for an update can be checked either by the script (Command line - return code) and the main script can prompted the user OR use a command line option to request a prompt (I'll add that to the spec.).

Just create a .au3 put it in your Includes folder and just Include it at the top of each of your scripts. 1 line to add to each script and 1 .au3 to edit if needed. You would have to compile all your programs once you update anyways and once that is in place (all programs compiled with new .au3) then it would be a flawless update. The programs will check downloaded .ini and if update is available it would update, including updating the edited .au3 if needed!

Yep I've been down that road and there are a few cons

Cons:

1. If the updater is edited

1.1 ALL scripts would have to have versions numbers increased.

1.2 ALL scripts would have to be downloaded by users even though it's main task is exactly the same.

2. On updates ALL updated scripts would have to be authenticated by the firewall. (many users will block the scripts)

3. How do you explain to your users that all of the scripts are "Phoning Home" whenever they are run.

4. A number of customers maybe behind commercial firewalls with strict rules so a customer Updater script can be created for them.

4.1 This also applies to computers that only use LAN updating.

Also what I'm proposing is a drop in solution for anyone that wants to use it.

All they have to do is to edit the script to point and there server and a few lines in each script and away they go. Oh and update the INI file.

Again thanks for the feedback!

John Morrison

[storme]

Thanks guinness, rcmaehl and D4RKON3

I'll be using "InetRead" and to make it easy the UDF I haven't looked through the UDF code yet but it looks like it might fit the bill.

Thanks for the comments!

John Morrison

[storme]

So anyone else have comments, feature requests or suggestions?

If not I'll add the spec to me todo and get something coded.

Thanks for any feedback

John Morrison