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