I am writing code in Visual Studio 2017, using C# for Unity.
Sometimes, when I add a breakpoint in some places, it is a hollow circle , opposed to the normal circle . When this happens, the breakpoint doesn't hit.
If I try and place a breakpoint on an empty line or method signature, I get a hollow breakpoint. But I will also get them on valid, debuggable lines of code. I can debug the hollow ones by finding a valid breakpoint above it, and stepping down.
The breakpoints are not disabled:
Why are my breakpoints hollow sometimes? What does it mean? How can I stop it?
In my case I saw this message in the Application Output window:
Resolved pending breakpoint for 'Android.Runtime.JNIEnv.RegisterJniNatives(System.IntPtr, System.Int32, System.IntPtr, System.IntPtr, System.Int32)' to [0x0](no debug symbols).
note that at the end of the message it says (no debug symbols). So just simply Cleaning and Rebuilding and also deleting bin and obj folders of all projects worked for me.
Had the same problem... closed Visual Studio and reopened, back to normal now.
Related
I am using the Visual Micro extension for Microsoft Visual Studio, which allows me to debug my Arduino project (in opposed to the Sketch IDE).
For some strange reason, when no breakpoints are present, it automatically adds a breakpoint at the beginning of the loop function.
When running via the debugger, I can simply remove it and continue running.
However, I cannot do the same when running without a debugger (i.e., upon power-up), since breakpoints seem to be "embedded" into the code as additional code segments (though I'm not really sure how explain the fact that the debugger allows me to remove a breakpoint).
Here is an illustration of the problem:
Now, I've been able to work-around it by adding a piece of "dead code" with a breakpoint:
if (0)
{
// insert a breakpoint here
}
But this feels kinda "clumsy".
I suppose that if there is a solution to this problem, then it lies somewhere in here:
But I have not able to find it, so any help will be highly appreciated.
Found the answer!
It turns out that all I needed was to hover on top of the breakpoint and read the tooltip carefully:
As you can read on the bottom line of this tooltip, in order to switch off that automatically-generated breakpoint, we only need to disable the Visual Micro's Tutorial Mode:
And voilà - we're all done!
It seems as though my breakpoints in Visual Studio 2012 have been persisting forever. No matter if I clear them during debugging, the red dots seem to re-appear the next time I attach to my IIS process. How can I permanently clear them? How do they get permanently set like that?
As mentioned in this link, go to Debug menu then Delete All Breakpoints Ctrl+Shift+F9 to get rid of all break points.
Or If you want to get rid of any particular break point, remove it before you start debugging (not during debugging)
If you are running in debug when you delete all break points, they won't really be deleted. After you get out of debug, and the project is not running, try to 'Delete all breakpoints' again, and it should clear them.
In Visual Studio 2013 Ultimate, if I edit my C# file (ASP.NET project) and then press F5, without explicitly saving, breakpoints are not hit. They are shown at runtime as empty red circles.
If I save, then press F5, they work as expected.
Even though saving before build is happening, I assume for some reason the debugging is happening against an older assembly? Holding the pointer over the empty circle reports "The breakpoint will not be hit. Source code is different from original version... to allow this disable the option 'Require source files to exactly match'"
I have tried resetting all my options to the defaults, but it still happens.
To exhibit this behavior, the edit seems to require a code change, not just adding a comment.
Tried all these but nothing works: "The breakpoint will not currently be hit. The source code is different from the original version." What does this mean?
Possible klunky fix:
However, I have experimentally added a post-build event, calling a small exe that does Thread.Sleep(5000). This seems to fix the problem!
So is my PC just too damn fast?!
I discussed this with MS, and they suggested the following on the command line
devenv /resetuserdata
This has fixed my problems. Don't forget to save your VS settings first, if you want keep them.
I am dealing with a puzzling situation here,and need any help I can get . I am using Visual Studio 2008 and have a dev site running on IIS. When I Attach to the process running in IIS, it attaches successfully(no errors). However when I attempt to debug, nothing happens. I have closed out my browser, done a restart on the application pool, and website, cleared cache, and even forced a rebuild in visual studio. Still I am unable to step into code. Any idea what I could have wrong here?
The breakpoint will not currently be hit. No symbols have been loaded for this document.
Your symbols might be wrong or missing. In extra rare circumstances you might need to step inside the function via assembly, only then VS picks up that you're actually calling your component.
Check if you have you set compilation debug=”true” in you web.config file?
I believe you need to debug the website from within Visual Studio in order for breakpoints to be hit. Use the green "play" button, or use F5, or just go to Debug > Start Debugging.
This is occurring in Visual Studio 2005, in an ASP.NET Web Application.
For example, if I try to set a breakpoint in the following code:
if (frustrated)
{
bool cry = true;
} <-- breakpoint here
It will set the breakpoint on the indicator margin, but when I actually hit F5 to debug the application, the breakpoint will flicker on and off (the little red circle literally vanishes then reappears) before disappearing altogether. Other breakpoints will work, just not ones ending on a closing bracket. This used to work, until I installed then uninstalled ReSharper (either it broke it, or its just coincidence).
EDIT: Just to reiterate - this is something that used to work, but doesn't anymore. I know I can put the breakpoint on a different line, but this is not what I want to do. I want it to work normally again.
EDIT 2: Resetting all of my settings did not help.
Any ideas?
Set the breakpoint on the line above it, instead of a closing brace.
If the breakpoint turns from a solid circle to an empty circle it indicates that the breakpoint could not be set usually because of a mismatch between the code and the actual binary module being loaded. This can be fixed by building or rebuilding suspect modules.
All projects opened while ReSharper was installed were affected. I went through each project and deleted the .suo file. After that, life was good - I can set breakpoints again!