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.
Related
I often find myself in a situation where I wish to break on several breakpoints in a run, but only for a while until I have seen enough on on those breakpoints and would like the Visual Studio to stop breaking on the breakpoints for the remainder of the current debug session.
I certainly do not want to delete all breakpoints because later I may change something in database or the code, and would like to perform a new, similar run to the one described above again.
I do not want to disable all breakpoints, since I want them to be activated again at the next debug run. At the same time I already have breakpoints, both active and disabled, in other parts of the code (which I am not currently interested in for instance) but I do not want to disable them and then try to remember later which I need for debugging a specific area/functionality of the code.
What I want is simply to be able to tell Visual Studio that "from now on as I resume execution, please ignore all breakpoints for the remainder of this debugging session. Thank you very much!"
So for the next debug run, all breakpoints should be hit again as they already were configured before as usual, but I mean at some point when I have seen enough I just want to continue execution without breaking. and without changing the status to "disabled" for all breakpoints - because doing so will make them stay disabled even at the next run, and I do not want to "Enable all" because I already had some breakpoints on my list which were disabled. And I certainly do not want to manually select/deselect breakpoints before every run just because I chose "Disable all" during a run.
Is this possible to and, in that case, how to do it?
Thanks!
I'm using VS2017 but hopefully the options are similar in VS2013:
Go to the Debug menu, then Windows > Breakpoints to open the Breakpoints window.
From here, the blue curvy arrows in the toolbar allow you to Export and Import breakpoints into an XML file.
So you could export all of your breakpoints, then delete them all. Later you can re-import them instead of having to set them all up again manually.
All of a sudden, my Visual Studio has begun to popup a message every time I want to break my ASP.net project.
How can I get rid of this dialog?
There is nothing to complete, only a debug session to get rid of. Clicking the "Stop Now" button will not immediately stop the execution, but wait some seconds.
From what I know, I have not changed any configuration to get this dialog.
Deleting all breakpoints (Menu > Debug > Delete All Breakpoints) and running in Debug mode fixed it. Unfortunately, nothing else did it for me. I had to again set the breakpoints that I wanted.
Alternatively, you can choose to work around this problem by choosing the Menu > Debug > Terminate All option instead of clicking the Stop Debugging (Shift + F5) button.
Microsoft announced that they have fixed it in the new release of VS 2017, per this link:
I tried deleting my log files and this fixed the issue for me. I think it stalled while trying to write when the files got so large, somehow.
Inside the project folder, try deleting all the log files in \bin\Debug\logs (path my vary depending on your own config)
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.
There is an annoying bug in VS 2008 that it will stop at some portion of the code that does not have a breakpoints. Even if I remove all the breakpoints. It will still stop at those points for unknown reasons (No exception or any problems like that). The only way for it not to stop is disabling the breakpoints. It is time consuming for me in some cases; I need to go through lots of clicks in order to go through them. Any help is appreciated.
I found out I did something silly. Instead of hitting the "continue" (F5) button, I hit the "stepping out" button instead. It might be a bug in VS 2008. I thought if I had removed all the break points, stepping out means "continue" because it should never had "stepped in" in the first place. But apparently it is not the case for VS. It will stop at some part of the code even though there are no break points set.
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!