.NET 源代码可以硬编码调试断点吗？

发布于 2024-07-09 12:35:29 字数 809 浏览 5 评论 0原文

我正在寻找一种在.NET（2.0，特别是C#）中让源代码触发调试中断的方法，就好像在该点设置了断点一样，而不必记住在调试器中设置特定的断点，并且不影响生产运行时间。

我们的代码需要吞掉生产中的异常，这样我们就不会破坏链接到我们的客户端应用程序，但我正在尝试对其进行设置，以便在调试器中运行时会弹出此类错误以进行分析，否则将被安全地忽略。

我尝试使用 Debug.Assert(false) 的效果并不理想，并且我认为 Debug.Fail() 也会有同样的行为。理论上它应该对生产没有影响，并且在调试时它确实会成功停止，但根据设计，（据我所知）如果您想忽略该错误，则无法继续执行，就像使用实际断点一样，就像在生产中我们吞掉错误一样。它显然也破坏了变量状态的评估，因为调试器实际上在本机系统代码中停止，而不是在我们的系统代码中停止，因此它的调试帮助是有限的。（也许我缺少某种返回事物以查看变量等发生位置的方法。???）

我希望有像 Debug.Break() 之类的东西，但它似乎不存在（除非可能在更高版本的 .NET 中？），并且似乎也没有其他 Debug 方法适用。

更新：虽然 ctacke 的答案最符合我的要求，但我也发现了 Debug.Assert() 的一个技巧——在调试器中运行时——暂停调试器，继续到 Debug.Assert 调用挂起的代码（以绿色突出显示，因为它位于框架代码中）并点击 Step-Out (shift-F11)，然后点击断言对话框中的 Ignore。这将使调试器在断言返回时暂停（并且能够继续执行，就好像它没有发生一样，因为它被忽略了）。可能还有其他方法可以做同样的事情（点击重试是否可以更直接地做到这一点？），但这种方法很直观。

原文

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.

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. ???)

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 Debug methods seem applicable, either.

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.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

千年*琉璃梦 2024-07-16 12:35:29

您可能正在追求这样的东西：

if(System.Diagnostics.Debugger.IsAttached)
  System.Diagnostics.Debugger.Break();

当然，它仍然会在发布版本中编译。如果您希望它的行为更像 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();
    }

然后在代码中添加对它的调用。

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:

    // 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.

回复收藏 0 原文

苏璃陌 2024-07-16 12:35:29

我曾经遇到过一种情况，这不起作用

System.Diagnostics.Debugger.Break();

，但这个起作用了

System.Diagnostics.Debugger.Launch();

I ran into a situation once where this didn't work

System.Diagnostics.Debugger.Break();

but this did

System.Diagnostics.Debugger.Launch();

回复收藏 0 原文

ペ泪落弦音 2024-07-16 12:35:29

System.Diagnostics.Debugger.Break？

回复收藏 0 原文

梦里南柯 2024-07-16 12:35:29

如果您只想使用一行代码而不是 4 行，请包装

#if DEBUG
       if (Debugger.IsAttached)
            Debugger.Break();
#endif

并

public static class DebugHelper
{
    [DebuggerHidden]
    [Conditional("DEBUG")]
    public static void Stop()
    {
       if (Debugger.IsAttached)
            Debugger.Break();
    }
}

使用

DebugHelper.Stop();

已添加的 DebuggerHiddenAttribute 来防止调试器在 Stop 方法的内部代码上停止并使用 F11 单步进入该方法。

If you want to have only one line of code instead of 4, wrap

#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();

DebuggerHiddenAttribute has been added to prevent the debugger from stopping on the inner code of the Stop method and from stepping into the method with F11.

回复收藏 0 原文