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

Answer 1

I just had the exact same problem. What solved it for me was deleting the .suo files belonging to the solution that contained the affected project/source file.

I also deleted my local symbolcache but I don't think that had anything to do with it.

(My solution contains multiple projects, one file (DataAdapter.cs) in one project was affected by this (VisualStudio put my breakpoints in the pdb belonging to System.Data.DataAdapter). I opened the .csproj file directly and was able to correctly set the breakpoint.)

Answer 2

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 3

I had a very similar problem. In my case the problem was a different target .net framework in one of the projects causing VS2017 to wrongly load a source file (with the same name) of another project, not the one being activated with

ObjectHandle handle = Activator.CreateInstance

Changing the project's target framework to be the same in all projects fixed it.

Answer 4

Delete all the .pdb files of the project where the break point is hitting wrongly. This will solve the issue.

Answer 5

I just had this issue on Visual Studio 2017 (Version 15.9.7), were break points were skipped and the debugger just "jumped" over return statements etc.

After a while I noticed, that I've recently added a .runsettings file to the project - and it turned out, that in my case configuring the CodeCoverage data collector is causing this problem. As soon as I removed this section:

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

from the .runsettings file, it worked like a charm again.

Answer 6

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.