Question

使用Visual Studio 2008，根据我的心情开始调试，我会附加到进程并以这种方式命中断点，或者我将System.Diagnostics.Debugger.Break()放在代码中的相关位置并在它开始调试时在这一点上休息。

有时我发现后者是必要的！

不谈论 F5 - ＆gt;在调试模式下运行一秒......

System.Diagnostics.Debugger.Break();

问题：

问：我很好奇每个选项之间的细微差别？

问）使用每种产品有什么好处和缺点？

我会开始吧......

Debugger.Break（）的缺点= 忘了Debugger.Break（）并将它们留在那里！

Debugger.Break（）的好处=开始准确调试你想要的地方而不会遇到其他不必要的断点，这些断点可能仍然存在于代码中，如果附加到进程就会被命中。

抢先仇敌

如果我使用的是Debugger.Break（），我只是先发制人，这无疑会说出来。我不理解正确的调试方式。

我只是想在这里开始对话，因为我认为根据情况有不同的调试方式。

Answer 1

我曾经在一个基于插件的应用程序上工作，它在启动时做了很多事情。它会在许多其他事情中进行插件发现。我无法直接从Visual Studio运行它，所以 F5 不是一个选项，但附加到调试器也不是一个选项，因为我需要很多次调试启动时发生的所有事情。我永远无法及时捕捉它与附加到进程。因此，我只是将Debugger.Break（）设置在我想要的位置。

另一个例子;我正在为PowerShell编写一个cmdlet。那些你不在Visual Studio中运行的;您从PowerShell命令行运行它们。它们通常是快速的小应用程序，并且你无法通过 Attach to Process 及时捕获它们。

Answer 2

除了BFree的答案之外，我发现Break在处理设计不佳的传统产品时偶尔会有用。这种特殊产品有吞咽或忽视异常的坏习惯，其记录机制（事实上，从未做过）没有正常工作。它经常违反许多需要客户“幸运”才能在运行时工作的良好实践。我开始添加快速代码：

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

到我专注于调试的特定位置。这使我更容易在不破坏客户运行代码的情况下查看正在发生的事情和违反的情况。（我的梦想是，这也有希望在我那些不那么有头脑的同事中找到了。）

是的，我知道这不是一个特别好的做法，我永远不会在新代码中这样做。但请相信我，如果你正在通过该代码库，你已经做了类似的事情。 ;）

使用System.Diagnostics.Debugger.Break（）优于Attach to Process有什么好处？

2 个答案: