debugging - Visual Studio breakpoints break in the wrong source file (or multiple files simultaneously) if multiple files have the same name

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 SettingsApplication Datadl3).^[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...