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.

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?