How can you make a silent update of the program, that is, without user intervention, etc. Only a question to update or not. The installer itself is stupid to download, that is, how to update the program exactly.

    5 answers 5

    I have the same principle with exe in the database, I download it, put it next to the program, calling it a upd.exe type and before I finish the program I do a batch file that tries to replace the current file with an updated one and run it in the background:

    BatFile := changefileext(Application.ExeName, '.bat'); assignFile(f, BatFile); rewrite(f); writeln(f, ':1'); writeln(f, 'erase '+ExtractShortPathName(Application.ExeName)); writeln(f, 'if exist '+ExtractShortPathName(Application.ExeName)+' Goto 1'); writeln(f, 'rename '+ExtractShortPathName(ApplicationPath)+'upd.exe '+ExtractFileName(Application.ExeName)); writeln(f, 'start '+ExtractShortPathName(Application.ExeName)+RestartParam); writeln(f, 'erase '+ExtractShortPathName(ApplicationPath)+'Upd.exe'); writeln(f, 'erase '+ExtractShortPathName(BatFile)); closefile(f); ShellExecute(FMain.Handle, 'Open', PChar(BatFile), nil, nil, sw_hide);

    and update passes silently and imperceptibly, profit

      After you have checked for updates (for example, compared versions) and start downloading program files into the program itself (with a shorter replacement) - but this is only relevant if the program is not very large - 5-15 files ...

      Already write the code yourself.

      This can be implemented via IdFTP.

      • No, I do this, the Firebird database in the Blob-field will be stored exe or installer. checks version and then downloads from the base and installs. - zerpico
      • > The exe or installer will be stored in the blob field. Not the best idea, I think. What prevents to store them in the file system? - Nofate ♦
      • > you start downloading program files into the program itself (with a shorter replacement) Here an important point: the update service should be an independent process. That is, we check for updates, if there are any updates, start the update service, and turn off. The update service downloads the update, replaces the files and starts the program when finished. - Nofate ♦

      I also keep my updates in the database. Conveniently, if the base is fully accessible, but the server itself is not. And more> 50 workstations in the local network. Worry around to run and update.

      The principle is as follows:

      • A dll is done to run through Rundll32 so that the update can be launched from the program (at startup, by timer, through the menu, etc.), but at the same time, that it works as a separate process.
      • On the database side, create a table where the files and information about them will be located (name, blob with the file itself, version, MD5-sum)
      • We register the system message for exchanging info with the program (for example: WM_AUTOUPDATE )
      • When you start the update, dll-ka reads a list of files in the database with files on the client and compares them
      • If you check the need to update the exe or dll , then check the version, and then MD5 sums
      • If the files are of some other format, then, simply - MD5 sums
      • Thus we obtain a list of what needs to be updated.
      • On this list, download new versions of files from the database in Windows TEMP
      • After the files have been downloaded, through Broadcast all running copies of your program via PostMessage
      • The program should respond to this message with a dialogue with a question like "Are we updating now or later?"
      • And at this time, the update process begins cyclic attempts to overwrite the program files (it is important to establish a delay between attempts in order not to load the system)
      • If the user, in response to the dialogue, clicked "Now", the program is closed and the exe-file is replaced with the next iteration of rewriting
      • If - "Then", then the cycle of attempts to rewrite continues until the program is closed.
      • Separate situation if you need to update the updating dll itself. Here it is necessary that she herself created a cmd-file which will replace it and will self-delete, and launch it.

      That's basically it. As a result, we get a variant without automatic update.

      For clarity, you can transfer the progress of the update to the program via WM_AUTOUPDATE .

      • In principle, I did the same thing just a slightly different implementation))) Thoughts converge))) - Shinobi

      I am changing the following update scheme. On the server, the version of the program is stored there; the folder name is the version of the program. It contains an exe-file that is updated. Access is available on port 80. There is a special table in the database on MySql where for each updated file the current version, the path to the program and the md5-hash of the file being downloaded are stored. The program starts, it checks the version of the current file, which lies next. If necessary, it receives from the server from where to download and md5-hash of the file. The old version is just backing up. Download the file immediately check its integrity by comparing md5-hash. Everything is normal, we delete the backup, and run the program. Not everything is normal, we delete the downloaded file, we return the backup instead, and in the log in the database we write that it was not possible to update. If the interesting scheme is discussed in detail in the article http://myshinobi.ru/kak-sdelat-obnovlenie-programmy-na-delphi/ . There are code examples.

        There is a ready-made component that will do everything for you - TMS TWebUpdate .

        • And it's not that. To horror just have to do. The update itself can essentially be done in the same program that will simply download, say, an archive with the program and unpack it into a folder. Just how to work with archives in Delphi - zerpico