With the last version of Parallels (the one with the Windows Live Mail does not work when adjust for time saving on bug) Visual Studio 2008 fails to create the RES directory when creating an MFC project on a .psf share. With the current version VS 2008 fails to properly create/compile the stdafx.cpp file for pre-compiled header when the project is hosted on a .psf share. However, if you specify that the pre-compiled header is created on a local directory (c:\temp for instance) it compiles. VS 2003 cannot create the project class view information .ncb file when the project is hosted on a .psh share. When you try to do a build, it fails because it cannot open the .pdb file. You can reproduce these bugs very easily, just get a copy of VS 2008 Standard edition and use the project wizard to create a vanilla MFC project. Do the same for VS 2003. Make sure to create the project on a .psf share.
Visual Studio 2008 stdafx.cpp won't compile via .psf share I'm having the same problem with VS 2008 v9 failing to properly create/compile the stdafx.cpp file for pre-compiled header when the project is hosted on a .psf share using Parallels Desktop 5 for Mac Build 5.0.9344 in WinXP SP3. When I shared the directory as an SMB share and then mapped a drive to it in the VM it worked. Unfortunately the compile time went for 14 seconds (when compiled from the WinXP C: drive) to 5:31 when compiling over a SMB share. This is my first time using Parallels. Did this ever work?
I don't remember it ever worked properly. Before the current update the only issue was that you need to manually create the RES directory. With the current update you need to specify a local directory for the pre-compiled header file.
Same thing here I have the same problems: can't compile stdafx.cpp and the /res folder could not be created. I need to work on a shared directory with Mac since the source files are common between mac application and windows application (multi-platform apps). Also, I found that IO stream functions (fopen, fputs...) don't work well on file open belonging to the .psf. In particular, I had to enable a large buffer to get my app working. Everything is OK is the file is located on C. Is there any solution for that? Have any of you tried if with VmWare or VirtualBox there are the same problems? Thanks!
There are two workarounds: 1. Make all your temporary directories local. This can be done via project profile. For example, you can set the project pre-compiled header directory to C:\TEMP. 2. You can do what I do, move the project local and run a background sync process to sync the content of the local project directory with that on the network. I haven't tried VirtualBox but I did try VmWare last year. The VmWare share drive implementation was extremely slow such that compiling on the Mac share drive simply took way too long to be worth anything.
Thanks, Phil. I guess I wil have to add the sync to keep the source tree mirrored. Few more feedbacks from my experience: 1) Moving only the .pch to c:\temp did indeed worked. However, I have got a subsequent error in the linker: "LINK : fatal error LNK1000: Internal error during IncrBuildImage". I solved this specific problem by installing the KB948127. 2) The following is the most challenging problem (and maybe a clue for the Parallels developers, to try to isolate a specific problem). In my project I make use of custom build steps for generating state machine C++ code. The tool involved is a simple command line application that opens a file, write lines using fputs, fputc and then closes the file. If the file belongs to the .psf share, there are strange problems: the output is "garbled in time" (i.e. lines look overlapping). This suggests a buffering flush problem. So I tried this: a) after opening the file in append mode, set the buffer size to zero, with setvbuf( output_stream, NULL, _IONBF, 0 ). In this mode, I had the **worst** case of output (just random stuff) b) increasing the buffer with setvbuf( output_stream, NULL, _IOFBF, 1024 ) things were better, but still problematic (some overlaps of strings). c) Finally, I have got everything ok with a large buffer: setvbuf( output_stream, NULL, _IOFBF, 1024*1024 ) This is a scary problem!!! (BTW, Visual Studio does indeed a enourmous activity in writing files...)
So far I have accomplished to compile my MFC projects by specifying the local VM drive for the intermediate files, output file and precompiled header files, i.e.: - Intermediate files: c:\Visual Studio\$(SolutionName)\Intermediate Files\$(ProjectName) $(ConfigurationName) - Output Files: c:\Visual Studio\$(SolutionName)\Intermediate Files\$(ProjectName) $(ConfigurationName) - Precompiled header: c:\Visual Studio\$(SolutionName)\Precompiled Headers\$(ConfigurationName)\$(TargetName).pch In this way all the sources can be stored in the .psf share. But I have a final annoyance that I cannot solve: the .rc file cannot be edited. Here it is how to reproduce the bug: 1) create a new MFC project on the VM C drive 2) copy the project on the .psf share 3) from the resource view table, open the .rc file. It will fail with "load failed" error. Is there any chance to see this problem solved without having to move the sources on the VM drive? Thanks.
MS Visual Studio and .psf paths still broken Chiming in on this thread to share that I'm also heldup with this issue. I'm supporting some legacy Visual Studio 2003 projects. Setting intermediary output to the local drive works, but then i have to reset the project prior to checking in my changes or other devs will have incorrect config. This used to work but with the most recent update seems to have broken. Lost many hours on this today.
Thanks for the info. I tried this patched version of Parallels Tools, but, for me, VS 2010 still gives problems. For example, the creation of /res folder in a new project wizard fails.
I found that for this to work I must open the Visual Studio project file starting with Z drive as opposed to the shortcut to Parallels Shared. In other words, the project file path should start with Z: rather than .psf. Hope this helps...
