Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Reinstall EXE on a Network setup
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00152817
Message ID:
00152848
Views:
23
>>>I used VFP 6.0 Setup wizard to create a Network setup for me that our users can run from the network to load the application on their own PC. Now I have updated the exe and have run setup again to place the new version out on the network. I wish to inform the user that a new exe is available. I noticed that the setup program registered my application in the users Add/Remove program in the control panel and when they run that it comes up with a screen that will allow them to Add/Remove or Reinstall or Uninstall. I want this to be as easy as possible so I tried the reinstall and noticed that everything, but my exe was updated (my ini files and config.fpw files were updated). The reinstall seems to be what I would like to do but it does not refresh my exe with the new version. I know I can do an uninstall and have them to a install and that works, but that causes them to reboot and find the setup again on the network and run it again. Is there any better method of getting a new
>>>version down to my pc users when I update the exe. Any suggestion would be appreciated.
>>
>>One common approach is to use a launcher application. A launcher is a fixed piece of code that starts up your app; it can, before starting your local copy of your executable, check the date/time stamp of your local copy of the application against the date/time stamp of an executable stored on the net; if the one on the net is more recent, it gets copied to the local machine and then launched. A simple example here - let's assume that the local copy that I want to fire at all times is stored in the CWD that my app launcher starts from and is called MYAPP.EXE, and that the most recent released copy of the executable is always available on the net at \\MyServer\MyAppDist\MYAPP.EXE; you could in your launcher do the following:
>>
>>
>>* some code probably precedes this
>>LOCAL aMyLocalCopy[1,5], aTheNetCopy[1,5]
>>IF FILE('.\MyApp.EXE')
>>   * I have a copy, check if it's the most recent one
>>   =ADIR(aMyLocalCopy,'.\MyApp.EXE')
>>   =ADIR(aTheNetCopy,'\\MyServer\MyAppDist\MyApp.EXE')
>>   IF DTOS(aTheNetCopy[1,3])+aTheNetCopy[1,4] > DTOS(aMyLocalCopy[1,3])+ aMyLocalCopy[1,4]
>>      *  Net copy is more recent
>>      COPY FILE \\MyServer\MyAppDist\MyApp.EXE TO .\MyApp.EXE
>>   ENDIF
>>ELSE
>>   COPY FILE \\MyServer\MyAppDist\MyApp.EXE TO .\MyApp.EXE
>>ENDIF
>>DO .\MyApp.EXE
>>
>>
>>Obviously, you can do more in the launcher app and generalize things, but this makes an interesting starting point.
>
>Thats a very good approach. I was hoping that I would not have to program a launcher app, but it may come down to that. Thanks for your time.

A basic launcher app is pretty straightforward to code - a project with a CONFIG.FPW and a couple of dozen lines of code for a simple one is about the bare minimum; depending on what else you want to do, a splash screen, some code to examine registry or .INI files to locate things, or whatever would be appropriate. In my case, the launcher handles the process of reading application registry values to locate where the actuall application data lives, and making sure that local copies of things are the latest version needed (I have a table that lists local components, the location of the most recent distribution, and a reference method for each to test the local version (ie Date/time stamp, .DLL versions, ProgID checks in the registry, etc.) It makes life much easier at runtime when the new version of my app requires updated .DLLs or specific .OCXs to be installed locally; it does require a mechanism to handle copying and registration, but you write that once...)
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform