C# .NET 源代码可以硬编码调试断点吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/361468/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Can .NET source code hard-code a debugging breakpoint?
提问by Rob Parker
I'm looking for a way in .NET (2.0, C# in particular) for source code to trigger a debugging break as if a breakpoint was set at that point, without having to remember to set a specific breakpoint there in the debugger, and without interfering with production runtime.
我正在 .NET（特别是 2.0，C#）中寻找一种方法，让源代码触发调试中断，就像在那个点设置了断点一样，而不必记住在调试器中设置特定的断点，并且不干扰生产运行时。
Our code needs to swallow exceptions in production so we don't disrupt a client application that links to us, but I'm trying to set it up so that such errors will pop up to be analyzed if it happens to be running in a debugger, and otherwise will be safely ignored.
我们的代码需要在生产中吞下异常，这样我们就不会破坏链接到我们的客户端应用程序，但我正在尝试设置它，以便如果它恰好在调试器中运行，则会弹出此类错误以供分析, 否则将被安全地忽略。
My attempt to use Debug.Assert(false)has been less than ideal, and I assume that Debug.Fail()would behave the same way. It should theoretically have no effect in production, and it does successfully stop when debugging, but by design there is (as far as I can tell) no way to continue execution if you want to ignore that error, like you could with an actual breakpoint, and like it would do in production where we swallow the error. It also apparently breaks evaluation of variable state because the debugger actually stops down in native system code and not in ours, so it's debugging help is limited. (Maybe I'm missing some way of getting back into things to look at the variables and so on where it happened. ???)
我的使用尝试Debug.Assert(false)并不理想，我认为它的Debug.Fail()行为方式相同。理论上它应该在生产中没有影响，并且在调试时它确实成功停止，但是根据设计，如果您想忽略该错误，则（据我所知）无法继续执行，就像您可以使用实际断点一样，就像在生产中我们吞下错误一样。它显然也破坏了对变量状态的评估，因为调试器实际上在本机系统代码中停止而不是在我们的代码中停止，所以它的调试帮助是有限的。（也许我错过了一些回到事情的方式来查看变量等等发生的地方。？？？）
I was hoping for something like Debug.Break(), but it doesn't seem to exist (unless maybe in a later version of .NET?), and no other Debugmethods seem applicable, either.
我希望有类似的东西Debug.Break()，但它似乎不存在（除非可能在更高版本的 .NET 中？），而且Debug似乎也没有其他方法适用。
Update:While ctacke's answer is the best match for what I was looking for, I have since also discovered a trick with Debug.Assert()--when running in the debugger--Pause the debugger, go to the code for the Debug.Assert call pending (highlighted in green because it is down in the framework code) and hit Step-Out (shift-F11), then hit Ignore in the assert dialog box. This will leave the debugger paused upon the return of the assert (and able to continue execution as if it hadn't occurred, because it was ignored). There may be other ways to do much the same thing (does hitting Retry do this more directly?), but this way was intuitive.
更新：虽然 ctacke 的答案是我所寻找的最佳匹配，但此后我还发现了 Debug.Assert() 的一个技巧——在调试器中运行时——暂停调试器，转到调试代码。断言调用挂起（以绿色突出显示，因为它在框架代码中处于关闭状态）并点击 Step-Out (shift-F11)，然后在断言对话框中点击 Ignore。这将使调试器在断言返回时暂停（并且能够继续执行，就像它没有发生一样，因为它被忽略了）。可能还有其他方法可以做同样的事情（点击 Retry 会更直接吗？），但这种方式很直观。
采纳答案by ctacke
You probably are after something like this:
你可能在追求这样的事情：
if(System.Diagnostics.Debugger.IsAttached)
System.Diagnostics.Debugger.Break();
Of course that will still get compiled in a Release build. If you want it to behave more like the Debug object where the code simply doesn't exist in a Release build, then you could do something like this:
当然，它仍然会在 Release 版本中编译。如果您希望它的行为更像 Debug 对象，其中代码在 Release 版本中根本不存在，那么您可以执行以下操作：
// Conditional("Debug") means that calls to DebugBreak will only be
// compiled when Debug is defined. DebugBreak will still be compiled
// even in release mode, but the #if eliminates the code within it.
// DebuggerHidden is so that, when the break happens, the call stack
// is at the caller rather than inside of DebugBreak.
[DebuggerHidden]
[Conditional("DEBUG")]
void DebugBreak()
{
if(System.Diagnostics.Debugger.IsAttached)
System.Diagnostics.Debugger.Break();
}
Then add a call to it in your code.
然后在您的代码中添加对它的调用。
回答by shahkalpesh
System.Diagnostics.Debugger.Break?
System.Diagnostics.Debugger.Break?
回答by CheGueVerra
I ran into a situation once where this didn't work
我曾经遇到过这不起作用的情况
System.Diagnostics.Debugger.Break();
but this did
但这确实
System.Diagnostics.Debugger.Launch();
回答by Lasse V. Karlsen
How about just configuring Visual Studio to pop up with the debugger even if you swallow it?
即使你吞下它，只配置 Visual Studio 以弹出调试器怎么样？
Do this:
做这个：
- Go to Debug->Exceptions...
- Find the right exception, or add it if it's your own
- Check the "Thrown" checkbox for the exception
- 转到调试-> 异常...
- 找到正确的例外，如果是您自己的例外，则添加它
- 检查异常的“抛出”复选框
This will stop Visual Studio on the location that exception is thrown, not just if it isn't handled.
这将在引发异常的位置停止 Visual Studio，而不仅仅是在未处理的情况下。
You can see more information here.
您可以在此处查看更多信息。
回答by Jonathan C Dickinson
A nice trick I found is putting Debugger.Break() in the ctor of your Exception.
我发现一个不错的技巧是将 Debugger.Break() 放在您的异常的构造函数中。
回答by Aren Cambre
In Visual Studio 2010, hitting Retryon a Debug.Assertdialog takes you to the failed debug assertion, just as if you had a breakpoint.
在 Visual Studio 2010 中，在对话框上点击Retry 会将Debug.Assert您带到失败的调试断言，就像您有一个断点一样。
回答by Sergey
If you want to have only one line of code instead of 4, wrap
如果你想只有一行代码而不是 4 行，换行
#if DEBUG
if (Debugger.IsAttached)
Debugger.Break();
#endif
into
进入
public static class DebugHelper
{
[DebuggerHidden]
[Conditional("DEBUG")]
public static void Stop()
{
if (Debugger.IsAttached)
Debugger.Break();
}
}
and use
并使用
DebugHelper.Stop();
DebuggerHiddenAttributehas been added to prevent the debugger from stopping on the inner code of the Stopmethod and from stepping into the method with F11.
DebuggerHiddenAttribute已添加以防止调试器在Stop方法的内部代码上停止并使用F11.
