VS2015 - "The breakpoint will not currently be hit. Unable to find corresponding location"

Currently I'm on 2018.2.15f1 with Visual Studio 2017 15.8.6, but I run into this every once a week in almost all Unity 2018 versions. How it appears and how it is fixed looks pretty random that something under the hood needs a solid fix!

Sometimes it disappears, sometimes it comes back. For a few of the cases `Clean Solution/Rebuild solution` worked. For a few others changing expression body to block body fixed. And in some cases it hits the breakpoints although it says it won't. I tried switching .NET versions to Rebuild library, and some other things like BOM, EOL. of cs files. I think I tried all solutions except Load symbols thing. Just I'm bored, project stalling and I'm going back to Debug.Logging.

And weirdly enough sometimes the ratio of not-hitting breakpoints increase as I try solutions, that is previously hitting breakpoints get infected and turn into that yellowish white breakpoint dots one after another.

 

Ok, more weirdly enough I went to lunch with Unity and Visual Studio open in the background (debugger not running), and all of the problem breakpoints were hitting when I was back half an hour later.

I'd seen a few breakpoints turned to red after a few seconds, so maybe VS is doing a kind of indexing in the background and some of these take too long. Meanwhile we try to fix the problem and a random fix looks it is working. Or some fixes accelerate that process. Can something like this be related?

 

Complete mystery to me. Still never got to the bottom of it.

 

I'm on Unity 2018.2 and I'm getting this issue too, but I get 100% of the time, previously I just used MonoDevelop on the older versions of Unity and it was fine, since upgrading, the first day I used Unity I was able to breakpoint in VS, but never again after that, it is infuriating that I'm now rendered completely unable to debug. I have tried all the suggestions floating around, it just won't work, and looks like it never will. I am thinking I need to open a support ticket but I have no faith I'll get a useful response... this is making development very difficult, I'm going to see what other tools I can point Unity too for debugging (maybe I can just go back to MonoDevelop?)

EDIT: Yes I was able to just go back to MonoDevelop, I just switched Unity's preferences (External Editor) to open by file type, since Mono is still installed and still associated. And while it isn't as nice and pretty as VS (trust me I love VS, I use it for everything else), it is able to hit breakpoints, so it's the winner.

 

It's 2019 and still happening ...... VS2019 + Unity 2019

Absolutely none of the solutions worked for me

FWIW

This is what worked for me:

I had a MonoBehaviour that is a partial class, as soon as I opened the second file of the partial class, breakpoints could be magically hit again

 

I switched to Jetbrains Rider roughly a year ago and have never looked back. Can't remember having an issue since. I know it's not super helpful in terms of VS, but I personally cannot recommend Rider enough.

 

I know that Rider is great and I too use it, it does not choke on a tooltip array of 1000s elements contrarily to VS .

But there are features in VS not in Rider hence why I (still) have to use VS.

 

Can I ask what features? I have found the feature set of Rider to be much better in my opinion and have not noticed anything lacking.

 

Mainly class diagram,

A few UX things like activating Unity window back when you continue execution so you don't have to Alt-Tab each time,

Debugger in general,

Other things like live unit testing, code map but these are for Enterprise version.

And you know, the interface, after years of VS it's hard to change even though I have the same font and many enticing features.

But don't get me wrong, the simple fact that Rider has R# and is fast and does not choke in debugging simple arrays is enough to switching entirely

VS + R# is just insane, many times it slow to a crawl after a long period, seems like you're on an 286

 

Resharper itself has some architectural and dependancy diagramming tools, if that is what you are referring to? Also, too bad it is not a 386. My DX/2 could just hit Turbo. : P I don't remember if my 286 had that.

 

I know and they're pretty good actually. But you know, good ol' class diagram has its qualities .

There's code map too but it's so sluggish that I stopped using it.

You can see at Jetbrains that they're planning to roll out stuff in 2019.1, hopefully we'll get many new features!

I do miss my DX/2 66 actually

Memories memories!!!

 

Looks like class diagrams might be one of the things to make it into 2019.1 actually. : D
https://youtrack.jetbrains.com/issue/RIDER-4321

But yeah, memories, lol. Much simpler times, indeed. Getting my first sound card was amazing, lol.

 

Yeah hopefully!

Back then I had a whopping 16mb of memory but no SB... When I got one however, I instantly became the king today it's all about the numbers, nothing more

There are still few good games today but it's not like how it used to be!

 

I also ran into same problem.
I followed a different way to add the script in Unity (may be a wrong way). I copied and pasted the script in Windows Explorer and renamed it. Also updated the class name and adapted the implementation where ever I wanted to.
After this, I was not getting breakpoints hit and got same error message.

Then I newly added the script from Unity and replaced the code which was added during above step.
After this breakpoints were hit.

 

Now I've got this issue on 2019.1.2f

 

Thank you Amazi! This worked for me. It's a super weird hack, but did the trick. After I added that line of code and it worked once, I was able to delete the code and it continued to work.... FOREVER!

 

Hey all,

Found a reliable workaround for our project. The issue is with .mdbs

Our codebase lives outside of unity. We compile it in visual studio and copy over the .dlls and .pdbs.
Not sure if the fault is ours or unity's, but in order for breakpoints to work, we should be updating/generating new .mdbs every time.

For whatever reason, the .mdbs do not always update. If your breakpoints aren't working, open your assemblies folder in windows explorer and verify the update date on the .mdbs are what you'd expect (or that the .mdb for your .dll exists at all).

The workaround:

We found that if we delete all our .dlls and .mdbs from our unity project, build in VS and copy them over, then select them in unity and hit "Reimport" (not reimport all, that will take forever!), this almost always updates the .mdbs.

It's a pain, and likely something to do with our post-build copy setup, but it is reliable.

Hope this helps someone

 

TLDR: Can be caused by partial classes with the same filename in a package used by your Unity project

In my case, the problem was using "partial" classes with the same filename within a package that the project was using. For example, I had a "SaveSystem" package that was imported by the "Core game" project. In SaveSystem there were two files named SaveSystem.cs that contained partial classes. When opening Core, VS would throw a warning about having two files of the same name. Fixing those warnings let my breakpoints be hit again.

 

Found a less burdensome, but still not ideal solution. There is an executable that runs on windows called pdb2mdb.exe. Found out running this against all our dlls after copying them into unity seems to generate/update all the .mdbs and allow debugging. Made a .bat script to do so. Of course this means manually clicking this .bat every time I want to debug now.

 

Here is a solution how I am able to debug any code without any issue now. I have been having this issue for 5 years so far making me wanna jump out of the window many times. Here is a list of checks I am doing before every debuging sesion and I haven't experienced a single debugging issue since than. Some steps may be ommited probably

- Detach Visual Studio debuger from Unity
- Stop unity project running if any
- Recompile your solution (deploy DLLs into plugin directory)
- Let Unity recompile imported DLLs
- Reimport all plugin directory in Unity (wait for the work-in-progress bar)
- Visual studio start doing dome heavy work (you can check in Task Manager cpu load). You need to wait till it finish processing and if you interrupt this process either by Unity Run button or attaching Visual Studio debuger to Unity you ended up with non-working breakpoints. Wait till you see the heavy cpu work is done in Task Manager - took 20 sec for me.
- Hit Unity play button and wait till it starts
- Attach Unity Debugger