我有一个由多个项目组成的VS(2008)解决方案，并非全部位于同一名称空间中。当我构建解决方案时，顶级项目TopProject使用的所有dll都将复制到TopProject \ bin \ debug文件夹中。但是，仅为其他一些项目复制了相应的.pdb文件。例如在使用NDepend时，这很痛苦。

VS如何确定将哪些.pdb文件复制到更高级别的bin \ debug文件夹中？我怎样才能让VS复制其他人呢？

编辑：

参考如下：所有dll都复制到中央位置，而没有其pdb。 TopProject仅具有对这些复制的dll的引用；但是，dll本身显然知道它们的pdb在哪里，并且(大多数)dll被正确地复制到调试文件夹中。

解决方案

从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.

因此，这里的"问题"(缺少更好的词)似乎是某些DLL是在调试模式下构建的(因此会发出PDB)，而有些是在发布模式下构建的(因此不发出PDB) 。如果是这种情况，应该很容易将-go修复到每个项目中并更新其构建设置。如果我们尚未对命令行选项进行任何调整，则这将是默认方案。

但是，如果不是这种情况，它将变得更加棘手。也许我们都处于发布或者调试模式。现在，我们需要查看每个项目的命令行编译选项(在项目属性中指定)。如果需要调试器，请将它们相应地更新为/ debug；否则，将其删除。

编辑以响应编辑

是的，DLL"知道"它们具有PDB，并具有指向它们的路径，但这并不意味着太多。正如其他人提到的那样，仅将DLL复制到给定目录不会解决此问题。我们还需要PDB。

在Windows中复制单个文件(某些"捆绑"类型的文件除外)(我不是Microsoft的专有名词，但是"完整的HTML软件包"是概念)不会复制相关文件。 DLL不是以"捆绑"的方式组装的，因此复制它们会留下其PDB。

我要说的唯一的答案就是更新将DLL移到那些中央位置并包括PDB的过程。不过，我很乐意被证明是错误的！

首先，永远不要做任何事情。清理解决方案，在调试模式下对其进行重建，然后检查是否已创建所有pdb文件。如果没有，那是你的问题。

如果创建了它们，但并没有全部复制它们，则可以通过创建一个post build事件来解决此问题，该事件将pdb文件手动复制到所需的位置。当然，这只是一种解决方法。

我唯一能想到的是解决方案文件已损坏。我们可以将.sln作为xml文件打开并检查其内容。检查按预期运行的项目的配置，并将其与未按预期进行比较。如果看不到任何内容，则必须在项目级别重复此操作。比较工作中的.csproj(或者任何其他项目)项目文件和非工作中的项目文件。

编辑以响应编辑：

如果我们只是手动复制内容，则也要手动复制pdb。我相信Dll不应"了解"有关pdbs的任何信息。只需将它们贴在目标目录中，然后喝杯咖啡即可。放松。

检查清洁溶液时，它是否已真正清洁。我看过VS甚至在清理后仍将文件挂在bin \ debug目录中。删除所有项目上的bin \ debug目录，然后重新生成。

正如其他帖子所说，我们可能遇到了编译器/损坏问题。

但是，正如Will所言，如果正在创建pdb文件，但未在所需位置显示它们，请创建一个后构建步骤。这是我为解决方案中的每个项目定义的构建后步骤。确保将所有输出文件都复制到一个公共目录中。

如果proj文件位于\ SolutionDir \ ProjDir中，则生成后步骤的第一行会将输出文件复制到\ Solution \ Bin \ Release或者\ Solution \ Bin \ Debug。
如果这是调试版本，则第二行将复制pdb文件。我不复制Release版本的pdb文件。

因此，\ SolutionDir \ Bin现在将所有输出文件包含在一个位置。

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