我有一个VS（2008）解决方案，包含多个项目，而不是所有项目都在同一名称空间中。构建解决方案时，顶级项目 TopProject 使用的所有dll都将复制到 TopProject \ bin \ debug 文件夹中。但是，仅为某些其他项目复制相应的.pdb文件。这很痛苦，例如在使用NDepend时。
VS如何决定将哪些.pdb文件复制到更高级别的bin \ debug文件夹中？我怎样才能让VS复制其他人？
编辑：
引用如下：所有dll都复制到一个中心位置，没有它们的pdbs。 TopProject 仅引用了这些复制的dll;然而，dll本身显然知道他们的pdbs在哪里，并且（大部分）被正确地复制到调试文件夹。
答案 0 :(得分：11)
来自MSDN：
程序数据库（PDB）文件成立 调试和项目状态 允许增量的信息 链接的Debug配置 你的计划。创建PDB文件 当你编译一个C / C ++程序时 / ZI或/ Zi或Visual Basic / C＃/ JScript .NET程序 /调试。
所以看起来这里的“问题”（缺少一个更好的词）是你的一些DLL是在调试模式下构建的（因此发出PDB），有些是在发布模式下构建的（因此不是发射PDB）。如果是这种情况，应该很容易修复 - 进入每个项目并更新其构建设置。如果您没有对命令行选项进行任何调整，那么这将是默认方案。
然而，如果不是这样，那将会变得更加棘手。也许你们都处于发布或调试模式。现在，您需要查看每个项目的命令行编译选项（在项目属性中指定）。如果需要调试器，请将它们更新为/ debug，如果不需要，则将其删除。
编辑以响应编辑
是的，DLL“知道”他们有PDB，并且有路径，但这并不意味着太多。正如其他人所提到的那样，只将DLL复制到给定目录，不会清除这个问题。您也需要PDB。
在Windows中复制单个文件，但某些“捆绑”类型文件除外（我不是微软的术语，但“完整的HTML包”是概念）不复制相关文件。 DLL没有以“捆绑”的方式组装，因此复制它们会使PDB落后。
我要说的唯一的答案就是更新你的DLL进入那些中心位置的过程，并包括PDB ......但我很乐意被证明是错误的！
答案 1 :(得分：3)
正如其他帖子所说，您可能遇到编译器/损坏问题。
但是，正如威尔所说，如果正在创建pdb文件，但没有显示出你想要它们的位置，请创建一个构建后步骤。这是我为解决方案中的每个项目定义的构建后步骤。它确保将所有输出文件复制到一个公共目录。
如果你的proj文件在\ SolutionDir \ ProjDir中，那么构建后步骤的第一行会将输出文件复制到\ Solution \ Bin \ Release或\ Solution \ Bin \ Debug。 如果这是一个Debug构建，第二行将复制pdb文件。我没有为发布版本复制pdb文件。
因此，\ SolutionDir \ Bin现在包含一个位置的所有输出文件。
xcopy /r /y $(TargetPath) $(ProjectDir)..\$(OutDir)
if $(ConfigurationName) == Debug xcopy /r /y $(TargetDir)$(TargetName).pdb $(ProjectDir)..\$(OutDir)
答案 2 :(得分：2)
首先，永远不要假设任何事情。清理解决方案，在调试模式下重建它，并检查是否已创建所有pdb文件。如果没有，那就是你的问题。
如果它们已创建，并且它们并非全部被复制，您可以通过创建手动将pdb文件手动复制到所需位置的后期构建事件来解决此问题。当然，这只是一种解决方法。
我唯一能想到的是你的解决方案文件已经损坏了。您可以将.sln作为xml文件打开并检查内容。检查按预期执行的项目的配置，并将它们与不符合预期的项目进行比较。如果您没有看到任何内容，则必须在项目级别重复此操作。比较工作.csproj（或其他）项目文件和非工作文件。
编辑以响应修改：
如果你只是手动复制周围的东西，那么也要手动复制pdbs。我相信，Dll不应该“知道”关于pdbs的任何事情。只需将它们粘在目的地目录中即可享用一杯咖啡。放松。
答案 3 :(得分：2)
检查清洁溶液的时间，确切清洁溶液。我已经看到VS将文件挂在bin \ debug目录中，即使在清理之后也是如此。删除所有项目上的bin \ debug目录并重建。