>I have a client who has a vertical market app that runs mostly on peer-to-peer networks in small office settings. In those settings, the idea is that the app treats one of the machines as the "server" and all the others as workstations. The EXE and data are on the server, while the workstations have VFP runtimes and shortcuts to the EXE.
>
>I've set up an InnoSetup installation that works for all this, giving the user the choice on each machine whether to install for a single user, a server or a workstation. But the one thing I haven't cracked is how to put the application in the Program Files hierarchy on the "server" machine. When I do that, the workstations say they can't get access.
>
>At the moment, I'm installing to a folder below the root to work around this. But I'd really like to figure out how to put the whole thing in Program Files.
>
>Anybody know how to make this work?

My understanding is that the "Program Files" folder is for installed programs that run only on the local machine. From what I've read, Vista builds on this and virtualizes the whole folder, which probably makes trying to set up and manage a share on a subfolder of it even more difficult. If I were you I'd forget about trying to set up a shared folder under Program Files.

You might think it less than elegant to create a folder on the root of the "server" computer (e.g. \MyApp) just for your app (I'd agree :)). A compromise I've used in the past is to create a root folder called something like "NetShare", and make sure that all shared apps/data are installed to one or more subfolders of that (e.g. \NetShare\MyApp). That way you have a distinct separation between programs and data that are for local execution only, and those that may be executed locally or by other machines on the network. It can also simplify tasks such as backup.

On a P2P network you don't have a system logon script available to map a drive letter to a network share. One way to achieve mostly the same thing is to create a batch file in a specific folder on every machine (including the "server") that gets run at the logon of any user:

@ECHO OFF
REM DriveMap.cmd
REM Located in C:\Documents and Settings\All Users\Start Menu\Programs\Startup\
REM Suppose we want everyone to access the shared app through a mapped drive Z:
REM First, delete any previously existing mapping of Z:
NET USE Z: /DEL >NUL
REM Now map Z: to what we want:
NET USE Z: \\ServerMachine\NetShare\MyApp /persistent:y >NUL
REM Other mappings, shared printer port redirection etc. go here
REM NUL redirect of messages helps suppress potentially undesirable messages from NET USE

For lurkers, the above ensures that everyone accesses the app through drive Z:, even someone logging on to the "server" computer. It's also more reliable than manually mapping the drive once per workstation and then hoping that Windows will "remember" the mapping (i.e. persistent) forever. For those wondering, yes, you can map a "network" drive letter to a share defined on your local machine as long as your version of Windows supports it (NT4, W2K, XP Pro - Vista I'm not completely sure, I imagine at least Ultimate and Business support it). For Windows OSs where it's not supported you can investigate the command-line SUBST utility. Of course, W95/98/ME machines should never be used as a "server" and basic reliability features such as regular, reliable and tested backup and mandatory "server" UPS should be in place.

Using a separate \NetShare folder is really just a variation on another standard practice. In some cases the "server" physical hard drive may come pre-partitioned into say, a C: and D: drive. For example, by default, Dell servers are set up this way (usually with ridiculously small C: drives and the remainder of the disk as D:). In that case you would just install your shared apps/data somewhere on drive D: to keep it separate from the server-specific local stuff on C:. OTOH workstations are usually set up with just a single partition C: so if you're using one as a "server" you can't take advantage of this - at least not without messing around with repartitioning utilities.

In one way, though, using a subfolder of C: is actually better than using a completely different partition on the same disk. If you defrag C: periodically, on average your shared data will be closer to the system files than they would be on a different partition so average hard drive seek times will be lower, and performance better on average. This is the "partial stroke" theory for improving hard drive performance: http://blogs.zdnet.com/Ou/?p=322