>>Thanks for your suggestions.
>>
>>Tried the following:
>>* cleared out the temporary folders
>>* Reset FOXUSER files
>>* Removed any TLB, VBR, DLL (just in case they might be interfering because of access privilege)
>>
>>Tried compiling to DLL again and got the same "hang" of environment. At least I see the APP being generated (IIRC this is a normal step when compiling to EXE and DLL. An APP file is first generated, and apparently there is a subsequent step that adds a "stub" that launches runtime). It appears the step where APP contents are built into DLL is failing -- there is a zero-byte DLL file. Doesn't get to the point where VBR and TLB are generated.
>>
>>Repeated same task by launching VFP using "run as administrator" -- no hang occurs, with DLL, TLB and VBR being generated.
>
>Do you have sufficient privileges in the DLL destination folder and/or other temp folder(s) that may be used in the build process?
>
>My understanding is versions of VFP prior to 9 were all pre-Vista, so they know nothing about folder and registry virtualization and the other new fun security aspects of Vista and later. I get the feeling even VFP9 is not wholly immune.
>
>As you no doubt know writing to C:\Program Files\... is restricted so having projects in subfolders of that is a bad idea. Even having FOXUSER.* there could be problematic. To get around this I've set up VFP on my Win7 Ultimate 64-bit box like this:
>
>C:\Dev -- root folder for dev tool installs e.g. C:\Dev\VFP\9
>
>C:\DevProjects -- root folder for dev projects e.g. C:\DevProjects\Client\Project\...
>
>I'm not sure I'd be happy putting dev projects as subfolders of Documents...My Documents. If you run VFP as administrator, you're nominally running as a different user account, which has a different profile (i.e. Documents library/folder). My understanding is Windows RunAs offers an option something like /noprofile when you elevate in this fashion, so although you get more privileges you still retain your current profile. But, I haven't done any explicit testing or research to confirm this. I feel happier with my custom setup and I haven't run into any unexpected or inexplicable errors like yours (although I don't have VFP6 SP5 on this box).

The project files are *not* in any of the restricted folders, and I *do* have full access rights to where the source and project files reside. I'm well aware of keeping stuff away from "c:\program files" and "c:\windows" from a long while back. And since I've got some background in Unix operations, I'm already in the habit of steering clear of keeping any user-updatable configuration information in any of the system folders. As for I've been handling the VFP environment -- I work with separate shortcuts for each major project that I work on -- each launching with a different "workspace" with its own resource file as well as temp folders (I'm keeping a separate "c:\projects" folder, with a sub-folder under that for each major project I'm working on). Also knowing how FOXUSER tends to get munged on occasion, I've got a backup of a "clean" copy for each "workspace" so that I can restore that if necessary. As I'd stated earlier, I'd been able to do the build of the DLL previously on this same computer -- the problem appears to have cropped up in the past couple weeks, and as far as I know, I've not made any (intentional) gross changes in the operating environment.