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?