Edit: This is now a confirmed VS bug. Hope the Connect page would be updated when it is resolved.
Try this (if you weren’t bitten by this issue already):
1. Create a new C++ project – any project type will do – at a volume other than your VS installation, say under D:\code.
2. Open its property pages, and under Configuration Properties\ General\ Output Directory, type exactly: \bin\
3. Go to Linker/Debugging and inspect the PDB location. It gives the innocent looking: ‘$(TargetDir)$(TargetName).pdb’. Now edit it and expand the Macros pane to dig deeper:
Your PDBs are all going to be generated at a drive different than the project’s (and thus, probably different than where you intended).
This is definitely new to VS2010, and calls for a deeper peek. Turns out the calculations of these macros are visible, at %PROGRAM FILES% \MSBuild\ Microsoft.Cpp\ v4.0\ Microsoft.CommonCpp.targets:
<TargetPath Condition="’$(TargetPath)’ == ”"
This format is quite readable as pseudo-code, and brief C# experiment shows that this code on the inputs above still gives the relative path ‘\bin\’ for $(TargetDir).
System.Io.Path documentation says:
Relative paths specify a partial location: the current location is used as the starting point when locating a file specified with a relative path.
‘Current location’ is the location of the running executable – unless a different directory is explicitly set. Since the full path ‘C:\bin\’ is displayed at the expanded macro page, I suspect somewhere VS runs GetFullPath over the result of the Microsoft.CommonCpp.targets code, resulting in a path on the volume of the VS installation.
I can’t verify any of it, but a while ago I opened an MS Connect issue about it, which seem to have received little attention from MS till now (can’t say I blame them – they seem to be bombarded recently with bogus issues). I’ll update in this blog if any new info is available.