>>>Even more simply, you can just include the Config.fpw file in the project.
>>
>>From my POV, that's not best practice, since it prevents creating a per-workstation CONFIG file, which, among other things, is used to direct where the temp files are placed. If you don't specify where to put them in a CONFIG file, VFP will put the in the startup directory for the app, which means that an .EXE fired in a network directory puts the temp files on the network, whcih often isn't the best choice from either an application or network point of view. Neither is a hard-coded local path, in case the target disk gets full or a cow flies by and you forget to create the temp file path.
>>
>>C:\ is about the only directory guarenteed to always be present, but using it is an incredibly bad move; the root directory of a drive has a limited number of entries on FAT volumes regardless of operating systems, users get upset seeing dozens of .TMP files left lying around in the root of a drive after a crash, and it just is not safe to delete all the files in the root of a drive...
>
>I caught that (your opinion) in the other branch of the thread. (talk about mixing metaphors!) It wasn't my intention to imply that adding the Config.fpw to the project was the only solution, and you make perfectly valid points.
>
>We use .INI's for desktop level on-the-fly application configuration and server based .DBF's for network level changes, even though special configurations are *extremely* rare.

Where do you place the temp files is still the big issue; if you want them locally (in most cases that'd be my first choice, since it reduces network traffic, and most of the time a local hard drive is much faster than the network connection, especially when the LAN segment gets busy), you need to point VFP to that from the CONFIG file, or load the .EXE locally in the best location (at a minimum, you want to put it on a drive with plenty of free disk space, and the C: drive is usually notr the best choice if >1 local partition is available.

If you have a standardized configuration (which from the discussion doesn't seem to be the case from the original question), you're absolutely right - burn the CONFIG.FPW into the app and either put the .EXE in the right place locally, start it in the .EXEs home directory, and hunt out where the data files are in the registry, or an .INI, or whatever mechanism you like. I do this with some of my clients that I develop installation and update systems for. the alternative with standardized configurations is to a standard place on every PC where the temp files can be put.

I find that the flexibility of creating a per-station CONFIG file is to my advantage, especially where I don't get to spec how each target system is configured.