Easy Way to Update EXE to all Workstations

[dylim]

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.

 

[GTGeek88]

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.

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.

 

[GTGeek88]

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...

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.

 

[Chriss Miller]

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.

 

[DDPL]

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.

 

[Chriss Miller]

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.

 

[dylim]

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,

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?

 

[Christoph_B]

Hi,
I'm using a VBS-Script starting my EXE. The script ist comparing the file-date of the exe-file (new and existing) and (depending on the date comparison) copiing the new exe-version and starting or just starting the existing exe.

Set oFSO = CreateObject("Scripting.FileSystemObject")
Set WshShell = WScript.CreateObject("WScript.Shell")

datei_netz = "S:\xxx\yyy\planung.exe"
datei_loc = "C:\aaa\bbb\planung.exe"

Set oFile_Net = oFSO.getfile(datei_netz)
Set oFile_Loc = oFSO.getfile(datei_loc)
'DateCreated?
Date_Net = cdate(oFile_Net.DateLastModified)
Date_Loc = cdate(oFile_Loc.DateLastModified)
if datediff("n",Date_Net ,Date_Loc) < 0 then
' msgbox("Daten ungleich")
ofso.copyfile datei_netz, datei_loc
else
' msgbox("Daten gleich")
' ofso.copyfile datei_netz, datei_loc
end if
WshShell.CurrentDirectory = "C:\aaa\bbb\"
WshShell.Run("C:\aaa\bbb\planung.exe")

Christoph

 

[dylim]

Hi,
I'm using a VBS-Script starting my EXE. The script ist comparing the file-date of the exe-file (new and existing) and (depending on the date comparison) copiing the new exe-version and starting or just starting the existing exe.

Set oFSO = CreateObject("Scripting.FileSystemObject")
Set WshShell = WScript.CreateObject("WScript.Shell")

datei_netz = "S:\xxx\yyy\planung.exe"
datei_loc = "C:\aaa\bbb\planung.exe"

Set oFile_Net = oFSO.getfile(datei_netz)
Set oFile_Loc = oFSO.getfile(datei_loc)
'DateCreated?
Date_Net = cdate(oFile_Net.DateLastModified)
Date_Loc = cdate(oFile_Loc.DateLastModified)
if datediff("n",Date_Net ,Date_Loc) < 0 then
' msgbox("Daten ungleich")
ofso.copyfile datei_netz, datei_loc
else
' msgbox("Daten gleich")
' ofso.copyfile datei_netz, datei_loc
end if
WshShell.CurrentDirectory = "C:\aaa\bbb\"
WshShell.Run("C:\aaa\bbb\planung.exe")

Christoph

Hi Christoph,

How does using oFSO = CreateObject("Scripting.FileSystemObject") to copy files compare to the "usual" COPY FILE command in VFP?

Thanks and best regards,

 

[Christoph_B]

Hi Dylim,

The script shown is running as a VBS-file (e. g. Start_planning.vbs) outside of the Vfp-Exe.
All users have this Script on their PC. I only copy a new version in the network-folder and the Script is doing copying and starting the exe.

 

[dylim]

Hi Dylim,

The script shown is running as a VBS-file (e. g. Start_planning.vbs) outside of the Vfp-Exe.
All users have this Script on their PC. I only copy a new version in the network-folder and the Script is doing copying and starting the exe.

What I am asking is.. is this way of copying files better or more efficient than the VFP COPY FILE command?

 

[Christoph_B]

I don't know. From my point of view the big advantage is the independence from the Exe, because all drives and folders are managed in the Script. The performance is (in the case) not the main bullet. If there is no change in the file-date there is no copy-process.

 

[Chriss Miller]

There's a very simple rule why people here talked about a separate loader.exe or a cmd batchfile or a vbs script file doing the actual EXE updating: When an EXE runs Windows protects the file and does not allow overwriting it, so an update always has to happen in separate code, be it another EXE or a command file. There's little concern about performance, this is the major reason.

You can try yourself, with an even simpler test of trying to BUILD an EXE from your VFP project while the EXE from a previous build runs, the final step to overwrite the EXE will then fail.

So you always need something separate. A vbs script or batch file has the simplicity to be adaptable variing situations not only by you but by network admins, anybody else from the customers (or your own companies) IT department or devops knowing enough about Windows shell commands.

 

[Christoph_B]

Hello Chriss,

exactly this is the (will known) reason why...

Explanation from Chriss (very good):
<<There's a very simple rule why people here talked about a separate loader.exe or a cmd batchfile or a vbs script file doing the actual EXE updating: When an EXE runs Windows protects the file and does not allow overwriting it, so an update always has to happen in separate code, be it another EXE or a command file. There's little concern about performance, this is the major reason.>>

Best regards

 

[dylim]

There's a very simple rule why people here talked about a separate loader.exe or a cmd batchfile or a vbs script file doing the actual EXE updating: When an EXE runs Windows protects the file and does not allow overwriting it, so an update always has to happen in separate code, be it another EXE or a command file. There's little concern about performance, this is the major reason.

You can try yourself, with an even simpler test of trying to BUILD an EXE from your VFP project while the EXE from a previous build runs, the final step to overwrite the EXE will then fail.

So you always need something separate. A vbs script or batch file has the simplicity to be adaptable variing situations not only by you but by network admins, anybody else from the customers (or your own companies) IT department or devops knowing enough about Windows shell commands.

At the moment, I am more inclined towards Christoph_B's use of VBS, though I will code it in VFP.

Suppose I have a new version of the loader/check EXE, how does this get updated?

 

[dylim]

Hello Chriss,

exactly this is the (will known) reason why...

Explanation from Chriss (very good):
<<There's a very simple rule why people here talked about a separate loader.exe or a cmd batchfile or a vbs script file doing the actual EXE updating: When an EXE runs Windows protects the file and does not allow overwriting it, so an update always has to happen in separate code, be it another EXE or a command file. There's little concern about performance, this is the major reason.>>

Best regards

How do we update the loader/updater exe since it will be protected when it is run?

 

[Tore Bleken]

In a perfect world, the loader is NEVER updated...! It should be a very simple program which just compares the local programs to the remote programs, and copy the newer ones. Then it starts the real program.
IOW a loader will typically only be a few lines. The list of files that needs to be compared, is stored in a separate file on the server, and is read by the loader.

 

[Chriss Miller]

Whoever said loaders need to be updated? I just said you can't integrate the update process into the application exe itself, that needs to be done separetely, i.e. therefore there's a loader or update exe or script.

And here's a situation you might come across: The server fails and is replaced. Share names change, mapped drive letters change or anything changes. Then a loader vbs or cmd can easily be amended, even if paths are hardcoded as in Christophs example vbs script. If a loader get's the path to files to compare and update from meta data files, these can be changed, true, but if that meta data is local you don't have a simple way of changing that configuration meta data for all clients without the need to go to each client. If that configuration meta data instead is located centrally on the server that's a problem as it's not available under the same name anymore.

You can point out as you like that the new server should be confiugured to get the old server name, have same share names and and/or be mapped with the same drive letter to not need a loader change. But reality most of the time will differ from ideals. For example another server is used instead of a replacement server because that's the fastest fix. Therefore its name and shares names and drive mappings are bound to other rules. Therefore and because the xcopy deployment name derived from using that simple shell command for the loader, a script file is always simpler to amend to such cases than a loader.exe. Nowadays you can also use robocopy or vbs or powershell scripts, etc. and if you fear of mongering with such files by users, well, they only need execute permissions, not read and even less so write or delete permissions.

Besides all that, you might want to extend the loader/starter/updater script and that's not limited to the developer. Obviously there are different tastes and opinions about the responsibilites and policies can play a role whether the one or other is preferred, no matter if talking about in house development or for a corporation with their own IT department or whatever else. Other applications like the Firefox browser or browsers in general have a separate update service running that will download updates, if updates are found and will then run that with the next start. Notepad++ does the same, without having such an update service running separately, it'll look for it's own updates on one of several alternative servers. And does apply them with next start.

Not every application has the need for an orchestrated update like database applications typically have when you have database changes necessary for new feature that will at the same time of allowing those new features also break the old version to work, i.e. you need to make the database update and force the new application version to all users at the same time.

The typical ways used for VFP applications stem from that main aspect differing from other software, there's more possible than is often suggested and you might want to update a loader.exe, too for other reasons like extended functionalities of that update process and you can let the main application exe update the loader.exe for that matter, when it's not simply centralized and you swap it out yourself.

 

[dylim]

Whoever said loaders need to be updated? I just said you can't integrate the update process into the applicaition exe itself, that needs to be done separetely, i.e. therefore there's a loader or update exe or script.

And here's a situation you might come across: The server fails and is replaced. Share names change, mapped drive letters change or anything changes. Then a loader vbs or cmd can easily be amended, even if paths are hardcoded as in Christophs example vbs script. If a loader get's the path to files to compare and update from meta data files, these can be changed, true, but if that meta data is local you don't have a simple way of changing that confuguration meta data for all clients without the need to go to each clients. If that configuration meta data instead s located centrally on the server that's a problem as it's not available under the same name anymore.

You can point out as you like that the new server should be confiugured to get the old server name, have same share names and and/or be mapped with the same drive letter to not need a loader change. But reality most of the time will differ from ideals. For example another server is used instead of a replacement server, therefore it's name and shares name are bound to other rules. Therefore and because the xcopy deployment name derived from using that simple shell command for the loader, a script file is always simpler to amend to such cases than a loader.exe. Nowadays you can also use robocopy or vbs or powershell scripts, etc. and if you fear of mongering with such files by users, well, they only need execute permissions, not read and even less so write permissions.

I see. In the off chance that I made an update to the loader, then that is the only time we update.

By the way, should the loader/update reside in each workstation just like the application EXEs? Or just on the server?

Thanks.