>>>Is there a clear article or case study discribing VFP installation process?
>>>
>>>I am trying to figure out the best method of application distribution in network environment. Application will run on a server and setup will install it there, regestering dlls and ocx on the server( let's say NT, to keep it simple). What tools should be used to install and register dlls on workstations? Is it possible to run VFP exe on NT without a local copy of VFP*.dll, other dll and ActiveX on a workstation?
>>
>>There's no need to install and register the OCXs and DLLs on the server unless the server is actually running the application, not just hosting the data.
>>
>>The easiest thing to do is to create a minimal runtime install with the setup wizard, and use that to install the VFP runtime support files, OCXs and associated .DLLs locally on each station. The maion program can reside on each station or on the server, at your option. You'll need to write enough of an install to create a shortcut to start the application in the appropriate location (this can be done with a Post Setup executable written in VFP if necessary, or a wrapper written with another tool like InstallShield, that can create shortcuts for you. George Tasker has posted a class that permits creation and modification of shortcuts here on UT if you decide to use a Post Setup executable to create your shortcuts.
>>
>>It's possible to register the common .DLLs and OCXs for the application in a singler location on the network; you'll take a performance hit, and there are other risks associated with doing so, such as ambiguities if something goes to update a registry entry referencing one of the shared network components when the network is not available. Install the VFP*.DLL set, and the support .DLLs and OCXs, to each local workstation; you'll have tremendously fewer headaches.
>
>Thank you for the response.
>The license model requires running one .exe, so it is to run on a server.

Without the .EXE, there's no need of any additional .OCXs or .DLLs on the workstation, since if the .EXE doesn't run there, the components aren't needed.

Where the physical file resides has nothing to do with where it executes. If there are multiple workstations involved, does the .EXE reside on the server, but get executed locally - then each workstation needs the runtime and runtime components. if the .EXE runs on the server, then only the server uses these components.

>Can you explain what should be done to register .DLL and .ocx on workstation without actually coping it? How severe could be performance penalties? Is not it easier to maintain ActiveX version control and upgrades once in one central location?

You can use REGSVR32 to register a file regardless of where it resides. The biggest problem with registering it on a non-local device is that if you have a reference to that remote device tht isn't permanent, it won't be available; e.g. if I temporarily map a drive M: to \\MyServer\MyApp, and I run REGSVR32 to register MyComponent.DLL, it's going to probably register the location of the component as being M:\MyComponent.DLL; the next time, if drive M: isn't mapped, or if it's mapped elsewhere, the component will not be found, and things won't work. You can coerce registry entries to UNCs, but that requires detailed knowledge of the registry keys used by each component.

If a large component is accessed over the net, it may take 20-30x as long to load as if it were on a local drive. YMMV.

Additional problems arise with non-local components. If a new copy of the component is copied to the server that requires reregistration, the workstations will get terribly confused. There's also the issue of uninstallation; the local machine tracks the number of local references to a component to determine if it's safe to delete that component during reinstall; it isn't aware of the reference count on other stations, so you may find the component disappearing after the first time you deinstall one station.

The approach that I take to my own maintenance is to maintain a repository of components in a central source, and have a launcher application that examines the components on the local system and compares them to the version on the server; if the copy on the server is more recent, it is copied down to the local station and registered. I do the same with the VFP executable; each station has its own local copy, and the server has the most recent release; the
launcher examines the application executable on the server, compares it to the local copy, and copies down the server version if it's more recent.

I think you need to rethink your strategy for deployment, with an eye towards what components are required on the server and which are required at each workstation.