Automatic Updater for application

[Victorio]

Hi,
My application running on many offices, and now when I update eXpress++ from version 260 to 265, I need update dll .
My default updater which I programmed function :
client / user run program
program go to FTP and read one text file on FTP (wia WinSCP FTP client) where is info about actually version
if program need update, winscp download files from FTP to local computer to update folder
an then run with runshell other application also in Xbase++ updatermy.exe and exit from application.
updatermy.exe runs and rewrite files, modules from update folder to main work folder.
Before updatermy.exe exit, he run with Runshell again main program and this is already updated.
Updater can close.

Files for update is on FTP , because client PC has access to it, and I do not want use some Web update systems, because there (on offices) was some
user access restrictions to enable internet access etc. , which can be problem.

So to this moment, when I update DBF,EXE,... files everything works fine several years.
But now I need update also DLLs but problem, because they was "open" with updatermy.exe program.

I want modify this system, to run updatermy.exe in other own folder where he has own DLLs, but I do not how do it.
When updatermy.exe run from other folder and open his own dll, then he can update also DLL in main program folder.
Is possible run with Runshell command other exe but also change work folder ?
Other way is only create batch file where is classic for example CD\MAINFOLDER\UPDATERFOLDER
Or some advice to better functionality ??

[skiman]

Hi,

I'm using inno setup to create a setup file. This doesn't use the DLL files.
- Download new update.
- Stop application.
- start update which can replace the DLL's and application.
- Start myupdate.exe which is created in Xbase and will use the new DLL's and can modify what i want to my dbf's.
- Start new version with new DLL files.

[Tom]

Chris - Victorio is talking about automated updates from inside the application. If you have your app on dozends of workstations, you can't run an InnoSetup on every client. You do this once, and then you get the update on the workstations somehow. But if you use a Xbase++-application to acquire this, it will not update runtime DLLs. We are working on the same issue.

[Wolfgang Ciriack]

I use InnoSetup, to install new main versions (changes to the DBFs (if needed), new runtime files etc., new exe and dll files of the app) on the main directory of my app (only one time). This can only be done, if no one uses the app.
If the client starts and there are newer exe or dll files of my App (same version, but new subversion, same runtime dlls), then my app quits and start a XBase app (not using any of the dlls for my app), which only copy the new app files to the client.
If this app cannot copy all needed files or the main version of the client does not match the server main version, the program quits, and starts a Client_Setup.exe (InnoSetup Clientsetup), which copies all files (runtime dlls, exe and dll of the app, tools, register ocx etc., sets the new version) needed for my app from the server to workstation and then starts the program.
Works now for many years without problems.

[Tom]

We created an Xbase++-app for that aswell, but if you need to deploy updates of the runtimes (Xbase++, eXpress++, other tools), which are used by the app and the updater, this fails.

[skiman]

Hi Tom,

Yes, I know that Victorio is looking for an automatic updater.

Your xbase application can download the update, start the update (innosetup) and quits. This way on the workstation the Xbase++ app is closed, and with innosetup you can replace whatever you want. When this is done, you can start an Xbase updater to maintain database modifications and so on.

A workstation can check on the server for a new version in a specific subfolder. If the update is found, the station can update automatically. If there are some services running on the server for automatic tasks, this can provide the download of the update from a webserver ans put this in the subfolder. So each station can notice this, and make the update.

If all the stations are using the EXE and the DLL's from a shared folder, this won't work. In that case you can make an update routine at night, and send a killtask to each station. When that is done, you can do the automatic update on the server.

[rdonnay]

Here is how I handled updates for an auto transmission rebuild operation.
This app started as a Clipper app in early 90's and was upgraded to Xbase++.
It was an in-house app, so the updates only need to be deployed to a server.
However, there were about 200 workstations connected on the LAN and 75 stores connected via WAN (Citrix).
This was an enterprise-level application which ran all sales and operations, except for accounting.
Therefore, it was unacceptable that the system could be shut down except from midnight to early morning.
Yet, we were making code changes and fixing bugs constantly.

Each time a workstation would log on, it would call a batch file on the server which would compare timestamps on all the runtime files on the server to those on the workstation and would copy everything new using xcopy /d. All Exes and Dlls would reside on each workstation. Citrix users runtime files would be on a folder unique to each store.

Updating the runtime was a simple as copying files to the server and overwriting the old files with the new files.
The workstation or store having the problem would be told to shut down and restart which would copy any new files to workstation and start the program.
Errors were automatically emailed to the programmers in real time with information about which workstation caused the error and all the necessary info.
The email contained a snapshot of the screen when the error occurred.
This was done by writing a record (with a pointer to the screen JPG attachment) to the SENDMAIL table. The record contained a snapshot of the screen when the error occurred. A service always ran that was responsible for sending the emails.

We used the Instant Messenger system to notify a workstation that an update was available or to communicate more about the problem.
Database was ADS and all structure and index maintenance was done by executing .SQL files. We would write those files to a folder on the server and a service would execute those files after midnight.

All the browse and edit screens were data-driven which reduced the necessity to make code changes when redesigning screens. Originally, the meta-data was stored in database tables in the Clipper version. A better solution in the Xbase++ version was to put the data in text files that could be easily edited and viewed with a text editor.

SQL files for updating table structure and indexes were created automatically by running a comparison of the ADS data-dictionary on the server to the ADS data-dictionary on the development system.

Operations were never shut down by errors caused by the developers. Such errors would usually affect only 1 user.

The complexities of maintaining so many screens, which were constantly changing, is what gave me the idea for developing the GUI command structure of eXpress++.

[Tom]

We had a solution based on XCOPY aswell, but then, this tool was eliminated by serveral administrators, or the application did not have the right to spawn a command window. Besides, it was hard to control.

[Auge_Ohr]

hi Victorio,

for Network i have VERSION.DBF on Server and App / Runtime are on Client Workstation

Code: Select all

{"VERSIONNR","N",6,3}
{"FILEPATH","C",80,0}

at Login App does compare Version with VERSION.DBF and give a "Warning" if Version is "lower"
now User logout from App and start "Update" which will transfer all Files from Server Folder to Client Folder

p.s. i do not delete "last" Version on Server so it can be "restore" in case "new" Version is not Stabil ...

[unixkd]

Hi All,

I developed an updater which I called AppLoader.exe and it is based on the Donnay xppload.prg. This Apploader.exe will check the current app.exe /???.DLL and if the update is newer then download it before executing the App.exe, works fine for us.

Joe