Visual Studio 2008 ASP.Net 调试僵尸断点被删除后又回来了

发布于 2024-09-07 17:30:26 字数 290 浏览 1 评论 0原文

在 Visual Studio 2008 中调试 ASP.Net 网站时,我在代码隐藏页面中设置了一个断点。我刷新页面或提交调用该方法,断点被命中。然后我删除断点并继续执行。我对代码隐藏页面进行了更改并保存。我再次提交或刷新,删除的断点又回来了!又被击中了,我又删了。我尝试过删除、禁用,但没有任何效果,如果我对页面进行更改,它会不断返回。这是非常烦人且低效的。我发现使断点永久消失的唯一方法是使用“调试”菜单中的“删除所有断点”项,这显然不太理想。我也能够在其他开发人员的机器上重现这一点。这是怎么回事?这是设计使然吗?是VS的bug吗?如何防止这些僵尸断点复活?

In Visual Studio 2008 while debugging an ASP.Net website I set a breakpoint in the codebehind page. I refresh the page or submit to call the method, the breakpoint is hit. Then I delete the breakpoint and continue execution. I make a change to the codebehind page and save it. I submit or refresh again and the deleted breakpoint is back! It is hit again, and I delete it again. I have tried delete, disable, nothing works it keeps coming back if I make a change to the page. It is extremely annoying and unproductive. The only way I have found to make the breakpoint permanently go away is to use the Debug menu Delete all breakpoints item, which is obviously less than ideal. I have been able to reproduce this on other developers machines also. What is going on here? Is this by design? Is it a bug in VS? How do I keep these zombie breakpoints from resurrecting?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

柠北森屋 2024-09-14 17:30:27

这是因为它的子断点仍然存在: MSDN 文章< /a>.

您的选择是:
- 停止调试会话,然后通过单击红色字形删除断点。
- 在断点窗口列表中找到断点并将其从那里删除。
- 使用宏清除调试会话之间的子断点,然后通过单击字形将其删除。[1] (有点奇怪,但工作时感觉很好。)
- 使用宏删除当前选定行上的断点。[2]

It's because its child breakpoints persist: MSDN article.

Your options are:
- Stop your debug session, then remove the breakpoint by clicking its red glyph.
- Find the breakpoint in the Breakpoint Window list and delete it from there.
- Use a macro to clean up child breakpoints between debug sessions, then remove by clicking the glyph.[1] (Quirky, but feels good when it works.)
- Use a macro to delete a breakpoint on the currently selected line.[2]

聽兲甴掵 2024-09-14 17:30:27

正如 @sgiffinusa 的链接所描述的那样:这是待定断点和绑定断点之间的区别。在附加调试器之前,它是一个挂起的断点,一旦附加调试器,它可能有多个生成的代码访问它,并且调试器将断点绑定到该代码的每个路径。我不明白……但这似乎就是发生的事情。 :)

似乎对我有用的一种解决方法是,不要通过单击边距来用鼠标切换断点,而是使用 F9 键(或您映射到的任何键)来关闭断点,然后按再次按 F9 将其重新打开,然后再次按 F9 以永远摆脱该该死的东西。

我不知道为什么会这样,但在这个办公室确实如此。

It's as @sgiffinusa's link describes: it's the difference between a pending and a bound breakpoint. Before the debugger is attached, it's a pending breakpoing, once the debugger is attached, it may have more than one piece of generated code accessing it, and the debugger binds a breakpoint to each path into that code. I don't get it...but that's what seems to happen. :)

One work around that seems to work for me is to, instead of toggling the breakpoint with the mouse by clicking the margin, use the F9 key (or whatever you have it mapped to,) to toggle the breakpoint off, and then press F9 again to toggle it back on, and then F9 once more to be rid of the dang thing forever.

I've no idea why that works, but it does in this office.

稚气少女 2024-09-14 17:30:27

我也遇到过这个问题。如果在删除断点之前停止调试(单击“停止”),断点应该会永久消失。

I've had this problem too. If you stop debugging (click stop) before you delete the breakpoint, it should go away permanently.

囍笑 2024-09-14 17:30:27

我认为这是设计使然。

在调试模式下删除断点,它是临时的。
删除设计模式中的断点及其永久断点。

I think this is by design.

Remove a breakpoint in debug mode and it's temporary.
Remove a breakpoint in design mode and its permanent.

枫以 2024-09-14 17:30:26

这可能是一个错误。使用删除所有断点 (Shift+F9) 或尝试在停止(而非运行)模式下删除断点。

It's probably a bug. Either use Delete All Breakpoints (Shift+F9) or try deleting the breakpoint in stopped (not Run) mode.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文