2

I use breakpoints in debugging my C#/.Net programs. Very often I use many "When hit" breakpoints to display messages in the Output window and keep going, so I can examine what the program is doing while it's executing.

But I often find that after editing code my breakpoints get moved, producing spurious or incorrect results and I have to go and delete my old breakpoints and make new ones.

Searching for this on Stack Overflow I find other programmers having this problem when building in Release mode, but I'm building with a Debug configuration.

How do I make my breakpoints stay put?

abatishchev
  • 98,240
  • 88
  • 296
  • 433
user316117
  • 7,971
  • 20
  • 83
  • 158
  • 1
    Sure, pretty inevitable. Using Trace.WriteLine() is of course the better way to do this. – Hans Passant Nov 26 '14 at 21:37
  • Trace.WriteLine() requires making changes to the code. Using this feature in the debugger doesn't, and besides it would be useful to know how to stop Visual Studio from moving my breakpoints in any event. – user316117 Dec 03 '14 at 17:21
  • What specific edits to the code do you make which causes this behavior? – theMayer Dec 03 '14 at 17:44
  • The edits that cause it don't follow any pattern. Sometimes I add or comment-out code and a breakpoint gets moved, sometimes it doesn't get moved. Also, I recently commented-out some code in a method. There were two breakpoints set in that method beyond where I put the comments. ONE of those breakpoints moved, the other one didn't! So the question becomes simple: When I set a breakpoint "here", what exactly does "here" mean to Visual Studio? – user316117 Dec 03 '14 at 18:03
  • You can try exporting the breakpoints (in an xml file) before making the changes and then again import it (not sure if the breakpoints get displaced or not) http://msdn.microsoft.com/en-us/library/vstudio/dd293657(v=vs.100).aspx – Deepak Mishra Dec 09 '14 at 07:37
  • "here" means the statement on which you have added the breakpoint. If you move the statement the breakpoint will also move with the statement. If you comment out the statement, it will hit the next statement. Changing the code while you are already in debug mode may sometime displace the breakpoints (when you get the error "the source code is different from the original version") – Deepak Mishra Dec 09 '14 at 08:32
  • does this happen with every break point or only on certain ones? – gmaniac Dec 10 '14 at 17:03

2 Answers2

5
  • Do you "share" files such as .csproj.user, .suo... with other developers of the project ?

If you are using a SCM exclude them from it, these files are not intended to be shared between different machines. To send them to another user with slightly different sources may cause this kind of funny mess.

More details about these files here : Best practices for Subversion and Visual Studio projects

  • This kind of thing could also happen if you manually edit files, outside of VS (with Notepad++ for example) : try to avoid this when you want to keep breakpoints at the right place, VS doesn't like it at all.
Community
  • 1
  • 1
AFract
  • 8,868
  • 6
  • 48
  • 70
  • Thank you. I've added another case which can also explain the OP issue. – AFract Dec 03 '14 at 17:45
  • They should be excluded if for no other reason than they are large, and change every time you open the program. Adds no value to have them revision controlled. – theMayer Dec 03 '14 at 17:46
  • I do not share this code with with other developers. I do not edit code outside of Visual Studio. – user316117 Dec 03 '14 at 17:52
  • One way to think of this question is: when I set a breakpoint "here", at this location, what does "here" mean to Visual Studio? Is it connected to the source code; is it connected to something lower-level, like in the CLI? What does Visual Studio anchor that breakpoint to? Does it vary with different versions of Vidual Studio or the .Net framework? – user316117 Dec 03 '14 at 17:58
  • There are stored in SUO file. I think it's related to line # (could be easily checked by editing a file outside of VS : try to move lines preceding a BP / change the content of the line which contains the BP for example, and tell us what happens !). For your problem, have you tried to remove SUO file ? It could maybe help (you will also lose some workspace settings too, but nothing very annoying). Also, check if your "new line" characters are consistent, a mix of \n / \r / \r\n could led to strange things. – AFract Dec 03 '14 at 19:02
1

There are many ways to examine the execution of program. Make sure you are generating full Debug Info for your project. Also check that csproj.user, .suo files aren't set as Read Only.

enter image description here

If these thing doesn't work, for your case I suggest you to use some console based output providing methods.

Try this one

Console.WriteLine("Currently executing this...");

The console here is the output window of VS. Select Debug from 'Show output from:'. enter image description here

If you want to halt the execution, use this code

Console.WriteLine("Currently executing this...");
System.Diagnostics.Debugger.Break();

You should do conditional compilation of your code so that this doesn't get released with the final product. Console.WriteLine() will not cause any problem but System.Diagnostics.Debugger.Break() will break application.

Sarvesh Mishra
  • 2,014
  • 15
  • 30