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