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

例

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

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

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

在某些工作站上，调试器将逐步通过正确的行(无论行高亮如何)。在另一些方面，它很乐意跨过无关的行(包括注释和空格)。我猜这取决于它选择显示哪个源文件。

我尝试过的

我已经拖网了。当调试文件(*.pdb)，源文件和编译后的代码不匹配时，似乎会出现这种问题。有很多可能的原因：重复的文件名(这可能会使debugger [5]感到困惑)，项目构建文件过时，无效的解决方案缓存或错误的构建配置。

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

• 检查了我的构建配置。

• 确保项目不是在发布模式下构建的。
• 确保我们没有启用代码优化。
• 确保正确加载了项目的调试模块。 (开始调试项目并检查Debug> Windows> Modules。这两个程序集均已列出，未进行优化，并且其符号状态为"已加载符号"。)
• 重置调试元数据和Visual Studio缓存。

• 关闭Visual Studio并删除解决方案缓存文件(*.suo)。[1]
• 删除每个项目的生成输出(bin和obj文件夹)。 (供以后参考：在Windows资源管理器中打开解决方案文件夹，然后在搜索框中键入以下内容：" type:folder AND (name:=bin OR name:=obj)"。
• 删除了程序集缓存文件夹(C:\Documents and Settings\\Local Settings\Application Data\dl3)。[2] [3]

这些都不起作用。我可以重命名其中一个文件(不重命名该类)以暂时解决此问题，但这远非理想。

我现在在哪里

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

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

文件的唯一命名似乎是我找到的唯一100％修复程序。在应用程序加载之前，禁用所有断点，然后在大多数情况下重新启用所需的断点。 Lambda函数中的断点仍然可以给您带来问题。

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

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

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

我还删除了本地符号缓存，但我认为这与它无关。

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

我在Visual Studio 2017(版本15.9.7)上遇到了这个问题，跳过了断点，调试器只是在return语句上``跳过了''。

一段时间后，我注意到，我最近向项目中添加了.runsettings文件-事实证明，在我的情况下，配置CodeCoverage数据收集器会导致此问题。
我删除此部分后：

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

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

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

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

尽管重命名其中一个文件可以工作，但是我发现最简单的解决方案是暂时禁用"其他"程序集的符号的自动加载。

这样，可以防止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。当然，这不会正确映射，因此您在调试时会看到各种奇怪的问题。

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

我有一个要保存为Version1的DLL子文件夹。甚至在删除了对该DLL的引用之后，然后又添加了对另一个项目工作室的引用之后，该引用拉入了现有的引用并进入了错误的源文件。我在子文件夹中删除了该DLL，然后Studio获得了正确的源。

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

摘要：

您也可以尝试清理并重建(而不是构建)所有项目。

我只是备份并删除了文件，然后将其重新添加到项目中，从而解决了该问题。我只是希望我在通过上述列表之前做到了:)

我有一个非常类似的问题。就我而言，问题是其中一个项目中的目标.net框架不同，导致VS2017错误地加载了另一个项目的源文件(具有相同的名称)，而不是使用

将项目的目标框架更改为在所有项目中都相同的问题已对其进行了修复。

我(在VS 2008中)碰巧有两个具有相同内存地址和相同关联文件的子断点。
这些断点是在流程运行期间的某个特定时间生成的。

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

删除该项目的所有.pdb文件，其中断点被错误地击中。这样可以解决问题。

对我有用的方法(VS2017)在Tools --> Options... --> Debugging --> General中禁用了此选项："要求源文件必须与原始版本完全匹配"，默认情况下已启用此功能，但我已将其打开。

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