c# - 使用 System.Diagnostics.Debugger.Break() 比附加到进程有什么好处？

Question

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

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

不是说 F5 --> 在 Debug模式下运行一秒钟...

System.Diagnostics.Debugger.Break();

问题:

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

问)使用它们各自的优点和缺点是什么？

我会开始...

Debugger.Break() 缺点 =忘记 Debugger.Break() 并将它们留在那里!

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

先发制人

我只是先发制人，他们无疑会说如果我使用 Debugger.Break() 我不理解正确的调试方法。

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

Answer 1

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

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