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

 

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

 

Occurring again in 2019.4.4f1, VS Professional 2019 (16.7.4). VS Tools For Unity 4.7.10. Very tired of this

 

Hello from 2020! I encountered this today. I found that anywhere in this particular file I would get this error message along with the "hollow" breakpoint. I could apply breakpoints in other files but not the one that I cared about. Annoying right?

Here's where it gets weird: I just ran the game as normal and pretended like the error didn't happen, the breakpoint did actually hit. So the error message was just lying.

Not sure if that matches other people's experience.

 

I have found that sometimes setting the breakpoint depends on the state of the editor yeah, and once you actually start play, the breakpoint location can be resolved.

 

Still happening in the latest versions of Unity. It is absolutely ridiculous we still can't use Visual Studio to debug our code.

 

Is there still no solution? I've been having this issue for so long now. Does this occur with other IDEs as well or just VS?
I've tried everything I can think of and all possible solutions online but nothing works. Sometimes it just works and 99% it just doesn't and I have to resort to debugging with print statements like in the dark ages!

 

I had the exact same error message. If someone reading this today against all odds may have the same cause of the problem as me: The script that i tried to debug with my breakpoint was not attached to any game Object.

 

Fixed this for me. Unity Console: "Missing Script" Warning. Fixed the warning, debugger worked again. I also i tried running build in solution in VS. Guess it wasn't completely compiling correctly outside Unity cuz of the warning.

 

This problem might be fixed if you delete Library and obj and all csproj and sln files in the highest hierarchy level of the project Folder (where you can also find your Assets folder) and reopen the project afterwards . Unity will rebuild its library and debugging will work again.

 

I guess the c# sln file which is being created by unity gets corrupted somehow and has to be rebuild.

 

You may have been wrote the method to a wrong class.
Thats why you may be getting "breakpoing will not be hit" error.
I had the same error and solved this error with this.