【问题标题】：Visual Studio breakpoints break in the wrong source file (or multiple files simultaneously) if multiple files have the same name如果多个文件具有相同的名称，Visual Studio 断点会在错误的源文件（或同时出现多个文件）中中断
【发布时间】：2012-09-07 03:03:07
【问题描述】：

在我正在处理的团队项目中，如果解决方案中存在另一个同名文件，则在文件中设置断点（例如 IdeasController.cs）将导致调试器行为不稳定。我已经在几个开发人员的工作站上重现了这个问题。

示例

我在我们的 Web API 中的IdeasController.cs 中设置了一个断点：

另一个名为 IdeasController.cs 的文件存在于我们单独的 MVC 4 Web 项目中。在下面的屏幕截图中，调试器显示了Api->IdeasController 源代码，但行高亮与Web->IdeasController 的代码结构匹配。断点是重复的，其中一个位于注释块的中间。

断点窗口同时显示两个文件中的断点：

在某些工作站上，调试器会逐步执行正确的行（无论行高亮如何）；在其他人身上，它会愉快地穿过不相关的线条（包括 cmets 和空白）。我猜这取决于它选择显示的源文件。

我尝试过的

我浏览了互联网。当调试文件（*.pdb）、源文件和编译代码不匹配时，似乎会出现这种问题。有很多可能的原因：重复的文件名（可能会混淆调试器^[5]）、过时的项目构建文件、无效的解决方案缓存或不正确的构建配置。

这些是我找到并尝试过的解决方案：

检查了我的构建配置。
1. 确保项目不是在发布模式下构建的。
2. 确保我们don't have code optimization enabled。
3. 确保项目的调试模块已正确加载。（开始调试项目并检查Debug > Windows > Modules。两个程序集都已列出，未优化，并且符号状态为“已加载符号”。）
重置调试元数据和 Visual Studio 缓存。
1. 关闭 Visual Studio 并删除解决方案缓存文件 (*.suo)。^[1]
2. 删除了每个项目的构建输出（bin 和 obj 文件夹）。（供将来参考：在 Windows 资源管理器中打开解决方案文件夹，然后在搜索框中输入：“type:folder AND (name:=bin OR name:=obj)”。
3. 已删除程序集缓存文件夹 (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3)。^[2][3]

这些都没有任何效果。我可以重命名其中一个文件（不重命名类）以临时解决该问题，但这远非理想。

我现在在哪里

我最新的 Google 搜索的第 14 页。建议将不胜感激。 :)

【问题讨论】：

是的，真的很烦人。这个错误至少从 Visual Studio 2008 开始就存在。我知道的唯一解决方法是重命名源文件，就像你自己发现的那样。
有趣的是，文档中提到了这个错误：msdn.microsoft.com/en-us/library/h6aesyw2%28v=vs.100%29.aspx。但是他们建议的解决方法（手动输入源文件的完整路径）似乎不起作用，至少在 VS 2013 U2 中对我来说是这样。
在 Visual Studio 2015 中仍然存在

标签： visual-studio debugging msbuild visual-studio-2012 debug-symbols

【解决方案1】：

我今天也遇到了同样的问题。我能够追溯到我在调试时忘记将平台目标设置为 x86 的事实。不幸的是，其他（x64 / Any CPU）在调试时可能会出现问题。至少 VS 2008 不喜欢它们。我想这是远离的另一个原因。

一些猜测...我认为调试器（在运行 64 位应用程序时）在某些情况下会以某种方式从文件中“窃取”断点。对我来说，这是因为首先加载了另一个具有相同文件名的程序集。如果我首先使用断点手动加载程序集，即使在 64 位模式下，我也能够避免这个问题：Assembly.Load("MyAssemblyWithBreakpoints");

希望这（我的第一个 stackoverflow 贡献）有所帮助。

【讨论】：

【解决方案2】：

我只是备份并删除了文件，然后重新添加到项目中，从而解决了问题。我只是希望我在完成前面提到的列表之前就这样做了:)

【讨论】：

这是唯一对我有用的解决方案，先试试这个

【解决方案3】：

我很高兴我找到了这篇文章，以为我是唯一的一个并且快疯了！我在使用 VB.Net 的 VS2012 中遇到了同样的问题，并且已经尝试了 OP 提到的所有内容。

文件的唯一命名似乎是我发现的唯一 100% 修复。在应用程序加载之前禁用所有断点然后重新启用您需要的断点在大多数情况下都有效。 Lambda 函数中的断点仍然会给您带来问题。

【讨论】：

【解决方案4】：

如果没有更好的选择，你可以在代码中设置断点：

System.Diagnostics.Debugger.Break();

只是不要忘记之后删除它......

【讨论】：

【解决方案5】：

我刚刚遇到了完全相同的问题。为我解决的问题是删除属于包含受影响项目/源文件的解决方案的 .suo 文件。

我还删除了我的本地符号缓存，但我认为这与它没有任何关系。

（我的解决方案包含多个项目，一个项目中的一个文件（DataAdapter.cs）受此影响（VisualStudio将我的断点放在属于System.Data.DataAdapter的pdb中）。我直接打开了.csproj文件并且是能够正确设置断点。）

【讨论】：

我不知道为什么，但删除 .suo 解决了我的问题。我只是将我的项目复制到另一个名称不同的项目中。当我调试新项目时，页面不断调用旧项目。断点也一样。现在它工作正常。感谢您在浪费了 3 个小时后节省了我的时间

【解决方案6】：

您也可以尝试清理和重建（而不是构建）所有项目。

【讨论】：

【解决方案7】：

我在 Visual Studio 2015 中遇到了这个问题。

我有一个带有 DLL 的子文件夹，我想将其另存为 Version1。即使在删除对该 DLL 的引用，然后添加对另一个项目工作室的引用后，它似乎也拉入了现有的引用并转到了错误的源文件。我在子文件夹中删除了那个 DLL，然后 Studio 得到了正确的源代码。

我在 [MSDN 上找到了一个有用的链接，该链接显示了如何在此链接上清除工作室中先前关联的源文件][1]。

总结：

在解决方案资源管理器中，右键单击解决方案名称（例如：解决方案“TestApplication”）并选择属性这将打开解决方案属性页对话框
在通用属性下，选择调试源文件
在“搜索这些路径以查找源代码文件 (Visual Studio .NET 2003)/包含源代码的目录 (Visual Studio 2005)”框中，根据需要添加、删除和/或重新排序目录
点击确定按钮

【讨论】：

【解决方案8】：

虽然重命名其中一个文件会起作用，但我发现最简单的解决方案是暂时禁用“其他”程序集的符号自动加载。

启动调试器并继续，直到遇到错误的断点。
使用调用堆栈窗口查找调试器实际设置断点的位置：
1. 右键单击带有黄色箭头的行并启用显示模块名称。（该行上也应该有红色断点符号。）
2. 现在可以在该行上看到程序集名称。
在“模块”窗口中找到该程序集（调试 > Windows > 模块）。
右键单击程序集并禁用始终自动加载。
停止调试器。
再次开始调试。

这样做可以防止 Visual Studio 调试器将断点映射到错误的程序集。然后它将首先从另一个 [大概] 正确的程序集加载符号，因此将断点映射到正确的程序集。

为什么会这样？

当两个不同的符号文件（PDB 文件）——对于两个不同的程序集——都引用同名的源文件时，这似乎会发生。尽管源文件完全不同，但 Visual Studio 调试器似乎有些混乱。

例如，假设有两个不同的文件，名称都为IdeasController.cs。第一个编译成程序集Api.dll，第二个编译成程序集Web.dll。

当调试器加载符号时，它会先加载Api.pdb 或Web.pdb。假设它首先加载Api.pdb。那么即使你在Web\IdeasController.cs 中设置断点，它也会在Api.pdb 中找到与IdeasController.cs 的匹配项。然后它将代码从Web\IdeasController.cs 映射到Api.dll。当然，这不会正确映射，因此您在调试时会看到各种奇怪的问题。

【讨论】：

【解决方案9】：

对我有用的（VS2017）是禁用Tools --> Options... --> Debugging --> General 中的此选项：“要求源文件与原始版本完全匹配”，默认情况下启用但我把它打开了。

但这还不够，我还必须手动删除解决方案中所有项目的 obj 和 bin 文件夹。

【讨论】：

【解决方案10】：

删除断点错误命中的项目的所有 .pdb 文件。这将解决问题。

【讨论】：

【解决方案11】：

我碰巧（在 VS 2008 中）有两个子断点，它们具有相同的内存地址和相同的关联文件。这些断点是在进程运行期间的某个时间产生的。

我注意到我在我的项目文件夹中复制了 .dll 文件，并解决了删除重复的 .dll，同时在调试文件夹结构中每个名称只保留一个 .dll。（例如，在我的调试文件夹结构下，/bin/Example.dll 和 /bin/Plug-in/Example.dll 都存在）。

【讨论】：

【解决方案12】：

我刚刚在 Visual Studio 2017（版本 15.9.7）上遇到了这个问题，断点被跳过，调试器只是“跳过”了返回语句等。

过了一会儿，我注意到我最近在项目中添加了一个 .runsettings 文件 - 结果证明，在我的情况下，配置 CodeCoverage 数据收集器导致了这个问题。删除此部分后：

<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>

从 .runsettings 文件中，它再次像魅力一样发挥作用。

【讨论】：

【解决方案13】：

我有一个非常相似的问题。在我的情况下，问题是其中一个项目中的不同目标 .net 框架导致 VS2017 错误地加载另一个项目的源文件（同名），而不是被激活的项目

ObjectHandle handle = Activator.CreateInstance

将项目的目标框架更改为在所有项目中都相同已修复它。

【讨论】：

【解决方案14】：

我遇到了同样的问题。在我的情况下，这两个项目都有相同的端口号。我能够通过更改其文件断点未命中的项目的端口号来解决它。

我的猜测是 IIS Express 正在缓存来自第二个项目的 pdb 文件，因为这两个文件具有相同的名称，并且这些项目具有相同的端口号。

【讨论】：

【解决方案15】：

我在另一个项目中使用相同文件名的另一个文件中设置断点时遇到了类似的问题。

这是由于其他项目的调试已启动，而我尝试设置断点的项目未启动。为预期项目执行 Debug > Start New Instance 后，断点创建工作正常。

【讨论】：