c# – 使用System.Diagnostics.Debugger.Break()优于Attach to Process有什么好处？

概述使用Visual Studio 2008,根据我的心情开始调试,我将附加到进程并以这种方式命中断点,或者我将 System.Diagnostics.Debugger.Break()放在代码中的相关位置,并在该点断开时开始调试. 我发现后者有时是必要的！ 不是在谈论F5 – >在调试模式下运行一秒钟…… System.Diagnostics.Debugger.Break(); 问题： 问)我很好奇每 使用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.

总结

以上是内存溢出为你收集整理的c# – 使用System.Diagnostics.Debugger.Break()优于Attach to Process有什么好处？全部内容，希望文章能够帮你解决c# – 使用System.Diagnostics.Debugger.Break()优于Attach to Process有什么好处？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。