Generating PDB files correctly for a native DLL using Visual studio 2013

Question

Yesterday, I went through our company's projects and updated them to fix a mistake (AFAIK) in how we configured them.

The issue was that under the property pages for the projects, under Configuration Properties -> C/C++ -> Output Files , we set Program Database File Name to $(OutDir)$(TargetName).pdb , the same value we had set Configuration Properties -> Linker -> Debugging -> Generate Program Database File .

My understanding is that the first property sets the location of the pdb file which contains symbols for the object files created during compilation of the source, while the second sets the location of the pdb file which contains symbols for the generated DLL. Is that correct?

Under this assumption, to prevent them from conflicting (I assume this is unwanted) I set the first property to $(IntDir)$(TargetName).pdb , but this broke the resulting pdb file (ie a debugger doesn't recognize it as the DLL's pdb file, and a co-worker ran a tool on it, and the signature does not match the one contained in the binary).

The strange thing is that using the value $(IntDir)$(TargetName)2.pdb (note the '2' suffix) fixes the issue. I don't understand why the name of the intermediate file would matter?

Note that Configuration Properties -> C/C++ -> General -> Debug Information Format is set to Program Database (/Zi)

Answer 1

I'd say you got it right: the compiler produces object files. At that time the DLL is not ready yet, so whatever that PDB file contains, it's not helpful in debugging.

After the linker has processed the output of the compiler, the DLL exists. At that time, a PDB makes sense for debugging. So the relevant file for debugging purposes is in Linker -> Debugging -> Generate Program Database File .

As @HansPassant mentioned in the comments, the Compiler setting should not be touched. Too bad it already happened. In a Visual Studio 2013 or 2015 C++ console application, the default value for C/C++ -> Output Files is $(IntDir)vc$(PlatformToolsetVersion).pdb , so the final name is something like Debug\\vc120.pdb or Debug\\vc140.pdb .

IMHO, changing the compiler's output file should not matter, as long as the name does not conflict with the linker setting. That's exactly what happened to you: the compiler name $(IntDir)$(TargetName).pdb (relative path) resolves to the same file as the linker name $(OutDir)$(TargetName).pdb (absolute path). In that case it may happen that the linker cannot write to the file because it's still in use by the compiler or other strange things.