c# – 使用System.Diagnostics.Debugger.Break()优于Attach to P
发布时间：2020-12-15 18:17:41 所属栏目：百科 来源：网络整理
导读：使用Visual Studio 2008,根据我的心情开始调试,我将附加到进程并以这种方式命中断点,或者我将 System.Diagnostics.Debugger.Break()放在代码中的相关位置,并在该点断开时开始调试. 我发现后者有时是必要的！ 不是在谈论F5 – 在调试模式下运行一秒钟…… Sys
|
使用Visual Studio 2008,根据我的心情开始调试,我将附加到进程并以这种方式命中断点,或者我将
System.Diagnostics.Debugger.Break()放在代码中的相关位置,并在该点断开时开始调试.
我发现后者有时是必要的！ 不是在谈论F5 – >在调试模式下运行一秒钟…… System.Diagnostics.Debugger.Break(); 问题： 问)我很好奇每个选项之间的细微差别？ 问)使用每种产品有什么好处和缺点？ 我会开始吧…… Debugger.Break()缺点= Debugger.Break()的好处=开始在你想要的地方准确调试,而不会遇到可能仍然存在于代码中的其他不必要的断点,如果附加到进程,它将会被命中. 先发制人 如果我使用的是Debugger.Break(),我只是先发制人,这无疑会说出来.我不理解正确的调试方式. 我只想尝试在这里开始对话,因为我认为根据具体情况有不同的调试方式. 解决方法
我曾经在一个基于插件的应用程序上工作,它在启动时做了很多事情.它会在许多其他事情中进行插件发现.我不能直接从Visual Studio运行它,所以F5不是一个选项,但是Attach to Debugger也不是一个选项,因为很多时候我需要调试启动时发生的所有事情.我永远无法及时捕捉它与附加到进程.因此,我只是将Debugger.Break()设置在我想要的位置.
另一个例子;我正在为PowerShell编写一个cmdlet.那些你不在Visual Studio中运行的;您从PowerShell命令行运行它们.它们通常是快速的小应用程序,并且你无法及时捕获它们与Attach to Process. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |