>I have an approach that works quite well that relies on the server install dropping the workstation install beneath the server's shared folder for the application. You run the workstation install from the share; it picks up the correct folder location automagically, and it ensures that any station that installs the application has adequate connectivity to reach the shared folder.
>
Very clever - I like the idea of "forcing" each W/S to have enough connectivity to at least see the share.

>This functionality isn't provided for free in Setup Wizard; you have to write a post-setup executable, which precludes the use of the new Visual Studio Installer instead, and the issues of deploying on the network server, ensuring that shares are set up properly, the necessary permissions have been granted, etc. aren't addressed by the tool. InstallShield is capable of doing the work. So are relatively lightweight scripting tools; if your site installs the WSH as a routine requirement, the WSH is an ideal tool for handling basic installation tasks, offers a strong programming environment (VBScript or JScript) and other benefits beyond just the install. I'll spare you the religious fervor behind my advocacy of it as a tool; let's leave it at if you don't want to spend on a good install product, installation using the WSH is a whole lot easier than kludging up batch files, and can offer a lot more flexibility and functionality. the WSH cn be downloaded from
>http://msdn.microsoft.com/scripting

I figured you'd weigh in with InstallShield and WSH :-) From what I can tell, you need the post-setup executable to write the share name to the WS registry, because AFAIK there's no way a plain VFP setup can reference its source folder (or write custom registry entries, for that matter).