Easy Way to Update EXE to all Workstations

dylim said:

Hi Guys,

I know this has been discussed. I would just like to get your various methodologies in doing EXE updates across multiple workstations using the app so I can decide on which to adopt.

Thanks in advance.

Click to expand...

I never do this. The EXE, the runtimes, and the data are on the server. The user just has a shortcut on their desktop to a Launcher.EXE program on the server (the user never runs the actual program directly). Launcher just runs the latest version of the program (also on the server, as mentioned). If the program is called MyProgram, I'd put in MyProgram001.EXE when first installed. If I modify the program, I just drop in MyProgram002.EXE. Launcher just looks for the latest version of MyProgramNNN.EXE (using the number, not EXE date/time) and runs that. So to run the latest version, the user simply needs to exit the program and restart it (immediately, in the case of important fixes, or at their leisure when the update is not critical). If I need to do a data structure update, I have a way of forcing the users out and keeping them out until I'm done.

GriffMG said:

A little thing about letting 10 users run an executable from the network at the same time... you have to get all 10 to exit the application
in order to update it. Try that a 2pm on a Friday before a public holiday...

Click to expand...

I have a way of forcing folks out. They are notified and can save their data (or not). If the elapsed period of time expires before forced shutdown, any changes are reverted and the program shuts down. It's not perfect - I probably need to do some refinement - but generally works well.

GTGeek88,

when finally - say - MyProgram007.EXE runs, and a user pins that to the taskbar, what then? Even after forcing users out, those not understanding this mechanism prevents updates from being done. They stick to their version until that becomes apparent (for example a table changes so the old version errors) and they get forced to update by running the launcher. To me that was a bummer when the simple batch file deployment was circumvented. And not even by bad intentions.

I have a small logon .EXE on the network that the user runs, this allows them to login and compares the password they enter against the users active directory password, so I don't store any passwords.

The small .EXE updates any newer files from the network to the local machine (including the main .EXE) and deletes any files that have been removed from the network master, .EXE then passes control to the main .EXE on the local PC.

I copy all the forms locally and run them form there, have hundreds of forms and 2-300 hundred users, so running it all locally definitely increases speed and allow single forms to be updated and available without users having to exit the main application.

I also have a routine that checks for the existence of a small text file that just has a number in it, when this file is created the user is notified that the application is going to close down in the number of seconds that is contained in the text file, it counts down then kicks them out. If you delete the file the count own is terminated and the application stays open. I do get some issues where VFP doesn't shut down (as stated above) because the user is in an update state or where users on VM's suspend their sessions but it works >90% of the time.

dylim,

to summarize, there are many aspects you need to think about which makes updating seem like an impossible task, but you could easily start with something that's working based on only comparing a local version.txt file with version.txt in an update directory and when the update version.txt value is pointing out a later version execute an update.cmd batch file that does the necessary steps to update. That's perhaps the simplest way to handle updates which also automatically does nothing, once the update has updated the local version.txt to contain the same version number as in the update directory. And think about cases like users keeping an EXE running or other special cases later.

Chriss Miller said:

dylim,

to summarize, there are many aspects you need to think about which makes updating seem like an impossible task, but you could easily start with something that's working based on only comparing a local version.txt file with version.txt in an update directory and when the update version.txt value is pointing out a later version execute an update.cmd batch file that does the necessary steps to update. That's perhaps the simplest way to handle updates which also automatically does nothing, once the update has updated the local version.txt to contain the same version number as in the update directory. And think about cases like users keeping an EXE running or other special cases later.

Click to expand...

Chriss,

What is your current practice regarding your EXEs... one EXE running in each workstation, or just one single EXE on the server being run by the workstations?