49

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

例子

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

代码中设置的断点

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

调试器突出显示与代码结构不匹配

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

断点跨越两个文件

在某些工作站上，调试器会逐步通过正确的行（不管行突出显示）；在其他人身上，它会愉快地穿过不相关的行（包括注释和空格）。我猜这取决于它选择显示的源文件。

我试过的

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

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

  • 检查了我的构建配置。
    1. 确保项目不是在发布模式下构建的。
    2. 确保我们没有启用代码优化。
    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]

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

我现在在哪里

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

4

15 回答 15

7

如果没有更好的选择，您可以将断点放在代码中：

System.Diagnostics.Debugger.Break();

只是不要忘记之后将其删除...

于 2014-08-01T08:50:30.573 回答
6

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

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

于 2014-05-15T14:28:19.483 回答
4

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

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

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

于 2015-07-01T09:19:37.563 回答
3

I had the same problem today. I was able to trace it back to the fact that I had forgotten to set the platform target to x86 while debugging. Unfortunately the others (x64 / Any CPU) can be problematic while debugging. At least VS 2008 doesn't like them. I guess this is yet another reason to stay away.

Some speculation... I think the debugger (while running a 64 bit app) somehow "steals" breakpoints away from a file in certain cases. For me it was because another assembly was loaded first which had the same file name. I was able to avoid the issue, even in 64 bit mode, if I first manually loaded the assembly with my breakpoints: Assembly.Load("MyAssemblyWithBreakpoints");

Hope this (my first stackoverflow contribution) helps.

于 2013-04-04T22:11:48.923 回答
2

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

过了一会儿，我注意到我最近在项目中添加了一个 .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 文件中，它再次像魅力一样工作。

于 2019-03-06T09:51:41.093 回答
2

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

  1. 启动调试器并继续，直到遇到错误的断点。
  2. 使用调用堆栈窗口 查找调试器实际设置断点的位置：
    1. 右键单击带有黄色箭头的行并启用Show Module Names。（该行上也应该有红色断点符号。）
    2. 程序集名称现在在该行上可见。
  3. 在 Modules 窗口（Debug > Windows > Modules）中找到该程序集。
  4. 右键单击程序集并禁用Always Load Automatically。
  5. 停止调试器。
  6. 再次开始调试。

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

为什么会这样？

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

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

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

于 2017-03-31T22:23:41.020 回答
1

我只是备份并删除了文件，然后添加回项目，解决了问题。我只是希望我在完成上述列表之前就这样做了：）

于 2013-09-17T10:12:32.057 回答
1

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

于 2016-09-01T20:08:25.293 回答
1

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

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

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

概括：

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

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

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

于 2020-02-18T02:15:52.840 回答
0

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

ObjectHandle handle = Activator.CreateInstance

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

于 2019-06-10T04:22:53.587 回答
0

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

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

于 2018-04-27T13:30:21.260 回答
0

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

这是因为调试是为其他项目启动的，而我试图设置断点的项目没有启动。在为预期项目执行 Debug > Start New Instance 后，断点创建工作正常。

于 2020-10-07T16:25:04.423 回答
0

对我有用的（VS2017）是在“要求源文件与原始版本完全匹配”中禁用此选项，该选项 默认启用，但我已将其打开。Tools --> Options... --> Debugging --> General

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

于 2017-11-20T10:02:06.280 回答
0

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

于 2018-02-15T11:59:47.673 回答