>The real problem for most Fox developers I would imagine is that they are not as advance as you when it comes to creating installs. Even if you develop one launcher app that always checks the workstation to ensure that it has the latest components installed, someone still needs to make sure the workstations have the Fox runtimes local or the reg entries as you suggested pointing to a server at some point.
>

That's why I advocate splitting up the install into multiple components. The 'main' station needs to install the VFP runtime and common components, with the registry entries that they require, as well as set up the application's 'home' on the network. Unless your application uses registry entries that are currently created by some post-setup executable, all the registration stuff can be done in the canned VFP runtime and common component install.

The 'other' stations need only install the runtime components and create the application-specific registry and system entries; they don't need to create the target directory structure and copy out the shared network files.

It appears to factor out to two installs, a 'get the cr@p out to the network and set up my home' component, run one time, and a 'put the runtime environment stuff in place on my system and sniff out the application home' component, run once per station.

A novel concept - the second, common component is a good fit for the Setup Wizard, in conjunction with a post-setup executable to do the sniffing and pointing task. Why not let the Setup Wizard do this one, and we'll come back to the post-setup executable in a minute.

The first component doesn't fit the Setup Wizard model - so don't use the Setup Wizard. Write a general network copying thingy in (pick a language other than VFP) - InstallShield, Windows Scripting Host, Delphi, whatever. Have this component pick where the application will live, install the files, and NOT DO ANOTHER BLESSED THING - it doesn't do the work of setting up the station.

One of the things that gets copied out to the network under the root directory for the application is the Setup Wizard install that everyone else is going to use. Let's put it in a directory called 'NetSetup' under the application. When a workstation needs to install the application, it runs the install from the NetSetup directory to put the runtime and shared components and do the registration two-step.

Now back to the post-setup executable. We need to have the post-setup executable sniff out where the application to create shortcuts, write registry entries/INI files, etc. e now have a way to do that. Since the post-setup executable is located in a subdirectory of where we want to be pointed, the post-setup executable can sniff out where the application lives by looking at where it resides - the application directory is the parent of the NetSetup directory. Sniffing out and setting up is easy now.

This looks a whole lot like what the big boys do - an 'administrative' install that sets up the network location, and a workstation install put out to the net by the admin install. Happy, happy, joy, joy!

Unless you want to delve into the bowels of relatively complicated install scripting, I'd make the installation of DCOM a task performed outside the workstation install script. I'd check for the presense of DCOM using the registry key I mentioned in a previous message in the post-setup executable, and terminate the workstation install as unsuccessful if it wasn't oresent. You could put copies of the various DCOM install .EXEs out to the network to make locating the right one easier. This avoids some of the trickier coding I do in InstallShield to handle possible restarting and continuation.

This is probably overkill for a one-time application install, but in a commercial distribution environment, it's necessary to maintain your sanity and give the appearance of knowing what you're doing. Once the skeleton for this type of thing is written, it's usable again and again. It's just like making the investment in a framework for your application development.

>At this point, if I knew all the reg entries needed for VFP 6, I would write a Delphi exe that runs in the log-in script copy and register the proper files if not already present.
>
>Did I give the impression that running workstation installs as being pointless? I did not mean to do so. I was trying to suggest to Bob that he should go through the install process at the workstations as it sounds like he is also depending on the Setup Wizard to do the job...
>
>>>>Questions:
>>>>
>>>>1) What are the names of the runtime files required by VFP 6.0?
>>>>
>>>>2) Do they install into \WINDOWS, \WINDOWS\SYSTEM, or can they install into the application homedir?
>>>>
>>>>I ran the VPF Setup utility to install an app on a clients server. However, it put the runtime files into his local Windowes dir, so other workstations don't have access to them. It seems pointless to have all workstations run the install. Is there a simpler way to do this - to insure that all workstations have access to the runtime files, which could be on the server somewhere?
>>>
>>>If you knew every registry entry to make, you could point the workstations at the DLL's on a file server. However, the client workstations will have better performance if the runtimes are installed locally. And with VFP 6, don't forget to install DCOM95 by itself, unless already there via an IE 4 install.
>>>
>>
>>You could register components that reside on the server using REGSVR32; if you do, their registry entries will point to them on the network. There is a problem in that when they register, the path must be permanently available to reference the file; either a UNC, or a permanently mapped drive letter, is suitable. REGSVR32 should reference the file to register with a path based on a UNC or permanently mapped drive to ensure this.
>>
>>DCOM95 is not unconditionally run; it only applies to Win95 (Win98 has its own DCOM install. DCOM should already be present if the Registry key HKEY_LOCAL_MACHINE\Software\Microsoft\OLE has a Registry value EnableDCOM with a value of 'Y', if it is not there, the OS-dependent DCOM install should be run.
>>
>>It is -not- pointless to have all stations run the install. I'd break up my install into two parts - one that installs the VFP runtime environment files, including ActiveX controls, automation servers, ODBC drivers, etc that all stations must reference, as well as creating a target directory structure and appropriate shortcuts. The second part could be contained in a post-setup executable that loads the application executable and initial data files if it finds that they are not already present.
>>
>>This strategy works especially well if you use a launcher app that's installed on the local system and copies over the latest executable from the net before running it each time the app starts; the post-setup executable puts the shared components in place if they aren't there, and then writes a registry entry or CONFIG.FPW that points to the appropriate location on the net to find everything.
>>
>>>I found this out the hard way yesterday. With VFP 5, you could set up an install through the network log-in script. I, too, wish they could have kept it simple with VFP 6. The price of progress, eh?