Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Best way to distribute a new executable on a LAN
Message
From
25/04/2001 16:39:34
 
 
General information
Forum:
Visual FoxPro
Category:
Installation, Setup and Configuration
Miscellaneous
Thread ID:
00497680
Message ID:
00499841
Views:
19
>Hi,
>
>I develop apps specifically for our company rather than a bunch of different clients. Frequently, I make changes to the code that does not impact the data structures. I've been using a batch file to copy the latest .exe from the server to the local drive and then execute it, thus ensuring that everyone gets the latest .exe on startup.
>
>But this leaves an ugly black DOS box running (and an additional program on the task bar) that I'd like to eliminate.
>
>I'd like to know how you all accomplish this type of update.
>
>TIA

Hi Larry,

I had this very similar problem, and more...
I was lazy to go to each client site and install new exe on each machine so, I developed the following:
- to refresh any program part: exe, fll, dll frx/frt etc.
- to refresh any VFP part (we are at 4th service pack)
- to refresh any shared part: ocx, dll
- distribute the updated parts in a zip
- distribute over internet via downloading.

So, I only send to my client an email today, that click on a button, because there is a patch zip.

The parts of the solution:
1.a. Download the refresh zip from internet. To a local folder. Any client program is capable for it. (If the client hasn't got any machine connected to the internet I send them the zip on a writeable CD. I have two refresh button on my programs: one for Refresing from Internet, and the other is for Refresing from CD)
1.b. then unzip it and copy the files to the shared server folder under dbf folder:
Structure of the folders:
dbf
|
+---\prg
|
+---\sys
|
+---\reg

In the dbf folder there is a file containing the current patch index. So after copying the files the patch index must be refreshed. (Avoiding unnecessary refreshing)
2. On starting any client exe will compare the locally stored patch index (that is zero at install time) against the commonly available patch index (it is contained in a file in the shared dbf folder on the server)
(It is locally configurable what should happen at time like this: nothing, ask the user or auto refreshing)
3. If refresghing is necessary, the client exe will terminate and a special refresh exe will make the actual refreshing. The refresh process: It has two main parts:
3a. Before the client exe terminates, checks the local refresh.exe version number against the shared refresh.exe. If it is newer, copies it to local.
Then executes it and terminates.
3.b The 'real' refreshing: The refresh.exe display a waiting message for the user informing about the state of the overall process and waits 'till the caller exe really terminates and then starts the refresh process.
It check all the 3 folders and their subfulders for files.
PRG folder and its subfolders requires simple copy process.
SYS folder requires carefull copy. (These files will be copied into the windows system subfolder.) These dll-s may be used by the system, so maybe it requires 'delayed installing at next startup'
REG folder requires also carefull copy and after it registering. (I only support ocx and dll files that has DLLRegister import function)
At the end, it refreshes the local patch index to the current number.
If delayed copy occured on hte end ask the user to restart the machine. If it wasnot, it starts the caller exe. (At starting this was a parameter.)

That is all my solution.

bb
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform