I'm working on a program which uses the System.Diagnostics.Debugger.Break() method to allow the user to set a breakpoint from the command-line. This has worked fine for many weeks now. However, when I was working on fixing a unit test today, I tried to use the debug switch from the command-line, and it didn't work.
Here's what I've tried:
A quick Google search didn't reveal anything, and the API documentation for .Net doesn't mention anything about this function not performing correctly. So... any ideas?
If a source file has changed and the source no longer matches the code you're debugging, the debugger won't set breakpoints in the code by default. Normally, this problem happens when a source file is changed, but the source code wasn't rebuilt. To fix this issue, rebuild the project.
To set a breakpoint in source code: Click in the far left margin next to a line of code. You can also select the line and press F9, select Debug > Toggle Breakpoint, or right-click and select Breakpoint > Insert breakpoint. The breakpoint appears as a red dot in the left margin.
In the Visual Studio toolbar, make sure the configuration is set to Debug. To start debugging, select the profile name in the toolbar, such as <project profile name>, IIS Express, or <IIS profile name> in the toolbar, select Start Debugging from the Debug menu, or press F5.
Press F5 and hover over the type variable again. Repeat this step until you see a value of I in the type variable. Now, press F11 (Debug > Step Into or the Step Into button in the Debug Toolbar). F11 advances the debugger (and executes code) one statement at a time.
I finally figured out what was happening. For some reason, something changed on my machine so that just calling Debugger.Break
wasn't sufficient anymore (still don't understand what changed). In any case, I can now cause the debugger to come up by using:
if (Debugger.IsAttached == false) Debugger.Launch();
Extracted from here (MSDN) the following note:
Starting with .NET Framework 4, the runtime no longer exercises tight control of launching the debugger for the
Break
method, but instead reports an error to the Windows Error Reporting (WER) subsystem. WER provides many settings to customize the problem reporting experience, so a lot of factors will influence the way WER responds to an error such as operating system version, process, session, user, machine and domain. If you're having unexpected results when calling theBreak
method, check the WER settings on your machine. For more information on how to customize WER, see WER Settings. If you want to ensure the debugger is launched regardless of the WER settings, be sure to call theLaunch
method instead.
I think it explains the behavior detected.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With