使用Visual Studio 2008,根据我的心情开始调试,我将附加到进程并以这种方式命中断点,或者我将
System.Diagnostics.Debugger.Break()放在代码中的相关位置,并在该点断开时开始调试.
我发现后者有时是必要的！
不是在谈论F5 – >在调试模式下运行一秒钟……
System.Diagnostics.Debugger.Break();
问题：
问)我很好奇每个选项之间的细微差别？
问)使用每种产品有什么好处和缺点？
我会开始吧……
Debugger.Break()缺点=
忘了Debugger.Break()并将它们留在那里！
Debugger.Break()的好处=开始在你想要的地方准确调试,而不会遇到可能仍然存在于代码中的其他不必要的断点,如果附加到进程,它将会被命中.
先发制人
如果我使用的是Debugger.Break(),我只是先发制人,这无疑会说出来.我不理解正确的调试方式.
我只想尝试在这里开始对话,因为我认为根据具体情况有不同的调试方式.
解决方法
我曾经在一个基于插件的应用程序上工作,它在启动时做了很多事情.它会在许多其他事情中进行插件发现.我不能直接从Visual Studio运行它,所以F5不是一个选项,但是Attach to Debugger也不是一个选项,因为很多时候我需要调试启动时发生的所有事情.我永远无法及时捕捉它与附加到进程.因此,我只是将Debugger.Break()设置在我想要的位置.
另一个例子;我正在为PowerShell编写一个cmdlet.那些你不在Visual Studio中运行的;您从PowerShell命令行运行它们.它们通常是快速的小应用程序,并且你无法及时捕获它们与Attach to Process.