Visual Studio breakpoints break in the wrong sourc

Question

In a team project I'm working on, setting a breakpoint in a file (say IdeasController.cs) will lead to erratic debugger behaviour if there's another file with the same name in the solution. I've reproduced the problem on several developers' workstations.

Example

I set a breakpoint in IdeasController.cs in our Web API:

Another file called IdeasController.cs exists in our separate MVC 4 web project. In the screenshot below, the debugger shows the Api->IdeasController source code, but the line highlight matches the code structure of Web->IdeasController. The breakpoint is duplicated, with one of them in the middle of a comment block.

The Breakpoint window shows the breakpoint in both files simultaneously:

On some workstations the debugger steps through the correct lines (regardless of the line highlight); on others it cheerfully steps through irrelevant lines (including comments and whitespace). I'm guessing this depends on which source file it chooses to display.

What I've tried

I've trawled the Internet. This kind of problem seems to occur when there's a mismatch between the debug file (*.pdb), the source file, and the compiled code. There are a lot of possible causes: duplicate file names (which can confuse the debugger^[5]), outdated project build files, invalid solution cache, or incorrect build configuration.

These are the solutions I've found and tried:

• Checked my build configuration.
  1. Made sure the project isn't built in release mode.
  2. Made sure we don't have code optimization enabled.
  3. Made sure the project's debug module was loaded correctly. (Started debugging the project and checked Debug > Windows > Modules. Both assemblies are listed, not optimized, and have a symbol status of "Symbols loaded".)
• Reset the debugging metadata & Visual Studio cache.
  1. Closed Visual Studio and deleted the solution cache file (*.suo).^[1]
  2. Deleted each project's build output (the bin and obj folders). (For future reference: open the solution folder in Windows Explorer and type this in the search box: "type:folder AND (name:=bin OR name:=obj)".
  3. Deleted the assembly cache folder (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).^[2][3]

None of these had any effect. I can rename one of the files (without renaming the class) to temporarily work around the problem, but that's far from ideal.

Where I am now

Page 14 of my latest Google search. Suggestions would be much appreciated. :)

Answer 1

If no better alternatives exist, you could put the breakpoint in code:

System.Diagnostics.Debugger.Break();

Just don't forget to remove it afterwards...

Answer 2

What worked for me (VS2017) was disabling this option in Tools --> Options... --> Debugging --> General: "Require sources files to exactly match the original version", which is enabled by default but I had it turned on.

That was not enough though, I also had to manually remove obj and bin folders for all projects in solution.

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

Answer 4

I was hitting this issue in Visual Studio 2015.

I had a sub-folder with a DLL I wanted to save as Version1. It seems even after removing the reference to that DLL, and then adding a reference to another project studio pulled in the existing reference and went to the wrong source file. I removed that DLL in the sub-folder then Studio got the correct source.

I found a helpful link on [MSDN that shows how to clear prior associated source files in studio at this link][1].

Summary:

1. In the Solution Explorer, right click on the solution name (ex: Solution ‘TestApplication’) and select Properties This will bring up the Solution Property Pages dialog
2. Under Common Properties, select Debug Source Files
3. In the Search these paths for source code files (Visual Studio .NET 2003) / Directories containing source code (Visual Studio 2005) box, add, remove and/or reorder the directories as desired
4. Click the OK button

Answer 5

I just backed up and deleted the file and then added back to the project, that solved the problem. I just whish i did it before going through the beforementioned list :)

Answer 6

I'm so glad I found this post, thought I was the only one and was going insane! I'm having the same problem in VS2012 with VB.Net and have tried everything the OP mentioned.

Unique naming of the files seems to be the only 100% fix that I've found. Disabling all breakpoints until the application has loaded and then re-enabling the breakpoints you need works most of the time. Breakpoints in Lambda functions can still give you issues.