views:

5022

answers:

6

I have a VS (2008) solution consisting of several projects, not all in the same namespace. When I build the solution, all the dlls used by the top level project TopProject are copied into the TopProject\bin\debug folder. However, the corresponding .pdb files are only copied for some of the other projects. This is a pain, for example when using NDepend.

How does VS decide which .pdb files to copy into higher level bin\debug folders? How can I get VS to copy the others too?


Edit:

References are as follows: all the dlls are copied to a central location, without their pdbs. TopProject only has references to these copied dlls; the dlls themselves, however, evidently know where their pdbs are, and (most of them) get copied to the debug folder correctly.

+3  A: 

From MSDN:

A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program. A PDB file is created when you compile a C/C++ program with /ZI or /Zi or a Visual Basic/C#/JScript .NET program with /debug.

So it looks like the "issue" here (for lack of a better word) is that some of your DLLs are being built in debug mode (and hence emitting PDBs), and some are being built in release mode (hence not emitting PDBs). If that's the case, it should be easy to fix -- go into each project and update its build settings. This would be the default scenario, if you haven't done any tweaking of command line options.

However, it will get trickier if that isn't the case. Maybe you're all in release or debug mode. Now you need to look at the command line compile options (specified in the project properties) for each project. Update them to /debug accordingly if you want the debugger, or remove it if you don't.

Edit in Response to Edit

Yes, the DLLs "know" that they have PDBs, and have paths to them, but that doesn't mean too much. Copying just DLLs to a given directory, as others have mentioned, won't clear this issue up. You need the PDBs as well.

Copying individual files in Windows, with the exception of certain "bundle"-type files (I don't Microsoft's term for this, but "complete HTML packages" are the concept) doesn't copy associated files. DLLs aren't assembled in the "bundle" way, so copying them leaves their PDB behind.

I'd say the only answer you're going to have is to update your process for getting the DLLs to those central locations, and include the PDBs ... I'd love to be proven wrong on that, though!

John Rudy
nope, not that simple. All projects are build in debug, and all have the same complie options.
Joel in Gö
A: 

@John Rudy

After you check all those settings, be sure you clean the solution and rebuild...

Nescio
yup, done that, didn't help.
Joel in Gö
+2  A: 

Are all projects ( the project, not a .dll/.exe file ) referenced to the "TopProject"?

TcKs
No, none of them: see my edit of the question.
Joel in Gö
+1  A: 

First off, never assume anything. Clean the solution, rebuild it in debug mode, and check to see if all pdb files are created. If not, that's your problem.

If they are created, and they're not all getting copied, you can get around this by creating a post build event that manually copies the pdb files to the desired locations. This is just a workaround, of course.

The only other thing I can think of is that your solution file has become corrupt. You can open your .sln as an xml file and examine the contents. Check the configuration for the projects that are acting as expected and compare them to those that aren't. If you don't see anything, you have to repeat this at the project level. Compare working .csproj (or whatever) project files and the non-working ones.


Edit in response to edit:

If you're just manually copying stuff around, then manually copy the pdbs as well. Dll's shouldn't "know" anything about pdbs, I believe. Just stick 'em in the destination directory and go have a cup of coffee. Relax.

Will
In fact, the (debug) dlls do know where their pdbs are, the path is encoded in them somewhere. And yes, I could do it by hand (or adjust my automatic copying), but I would like to know why the damn thing behaves like it does. And who said I'm not relaxed? I'm relaxed! Dammit! Aaaargh! :)
Joel in Gö
+1  A: 

Check when you clean the solution, that it is actually cleaned. I've seen VS leave files hanging around in bin\debug directories even after cleaning. Delete the bin\debug directory on all of your projects and rebuild.

Code Trawler
+2  A: 

As other posts have said, you may have a compiler/corruption issue.

But, as Will said, if the pdb files are being created, but not showing up where you want them, create a post-bulid step. Here is the post-build step I define for every project in my solution. It makes sure all output files are copied into a common dir.

If your proj file is in \SolutionDir\ProjDir, then the first line of the post-build step will copy the output files to \Solution\Bin\Release or \Solution\Bin\Debug. The second line copies the pdb file if this is a Debug build. I don't copy the pdb file for Release builds.

So, \SolutionDir\Bin now contains all your output files in one location.

xcopy /r /y $(TargetPath) $(ProjectDir)..\$(OutDir)
if $(ConfigurationName) == Debug xcopy /r /y $(TargetDir)$(TargetName).pdb $(ProjectDir)..\$(OutDir)
Dean Hill