在 VS10 中调试时未命中断点
我正在开发一个 C# 和 Silverlight 项目，每隔一段时间我就会遇到一个问题，调试时我的断点不再被命中。在编辑器中，它们没有变成透明的，所以我知道正确的代码已加载并正在运行。
一个例子是：
我有带有 getter 和 setter 的 Value ，它绑定到一个控件。当我在设置器中放置断点并从控件更改 Value 的值时，断点不会被命中。
我知道 IIS 重置可以解决此问题，但我想知道原因。还有其他人发现类似的行为吗？如果有人能够指出我可能的原因，我将不胜感激。
I am working on a C# and Silverlight project and every once in a while I run into an issue where my breakpoints are no longer getting hit when I debug. In the editor they are not turning transparent so I know the correct code is loaded and being run.
An example would be:
I have Value with a getter and setter and it is bound to a control. When I put a breakpoint in the setter and I change the value of Value from the control the breakpoint is not getting hit.
I know that an IIS reset fixes this problem but I would like to know the cause. Does anybody else find similar behavior? If anybody would be able to point me in the direction of a possible cause that would be much appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Visual Studio 2010中有一个选项：
确保未选中此项。这里假设断点是一个实心的红色圆圈，表明 VS 已经找到了它的调试符号。
或者，这些代码元素可以用各种调试属性之一进行修饰，即 DebuggerStepThroughAttribute、DebuggerNonUserCodeAttribute 和 DebuggerHiddenAttribute。即使存在断点，这些也可能会阻止调试器进入该方法。
当然，如果您正在调试的代码已经过优化，它可能看起来像是缺少行。我不确定如果您尝试在已优化的行上断点会发生什么。
如果断点变为空心（不是纯红色），则 Visual Studio 可能无法找到代码的调试符号。
如果重置解决了问题，可能正在调试的代码与原始源文件/符号之间存在差异，有一个选项可以使这一点不那么严格：
There is an option in Visual Studio 2010:
Make sure this isn't checked. This assumes that the breakpoint is a solid red circle, indicating that VS has found debugging symbols for it.
Alternatively, these elements of code could be decorated with one of various debugging attributes, namely
DebuggerStepThroughAttribute,DebuggerNonUserCodeAttributeandDebuggerHiddenAttribute. These may stop the debugger from going into the method, even if a breakpoint is there.Of course, if the code you are debugging has been optimised, it may look like it's missing lines. I'm not sure what happens if you try to breakpoint a line that has been optimised away.
If the breakpoint has gone hollow (not solid red), then Visual Studio likely cannot find the debugging symbols for the code.
If a reset fixes the issue, perhaps there are differences between the code being debugged and the original source file / symbols, there is an option to make this less strict:
很多次我在使用 winforms 应用程序时都会遇到这个问题。我做的简单的事情就是，在清理并重建解决方案之前重新启动 VS。如果没有效果，只需删除 bin 目录并再次重建即可。我做的最后一个选择是重新启动机器。
Many times i face this problem though while on winforms apps. So simple thing i do is, restart VS prior to Clean and Rebuild the solution. Then if nothing works out, just delete the bin directory and let rebuild again. The last option i do is restart machine.
我最近遇到了这个问题。虽然我没有找到确切的原因，但一个简单的修复方法是检查应用程序是否在调试模式（而不是发布模式）下运行并清理/重建解决方案。
I've had this problem recently. While I did not find the exact cause, a simple fix was to check the app is running in debug mode (as opposed to release) and clean / rebuild the solution.
在试图理解为什么在 vs2010 中运行代码时没有命中我自己项目的断点时发现了这个问题
通过查看高级编译选项下的项目属性并将“生成调试信息”设置为“完整”解决了 这个问题。
可能值得一提的是，我通过右键单击我想要调试的函数，使用非常方便的 TestDriven.net 的“Test With -> Debugger”跳转到我想要调试的代码。
Found this question while trying to understand why my own project's breakpoints weren't being hit while trying to run code in vs2010
Solved it by looking at the project properties under Advanced Compile Options and setting Generate Debug Info to Full.
Might be worth mentioning I jump into code I wish to debug by using the very handy TestDriven.net's "Test With -> Debugger" via a right click on the function I wish to debug.
（至少）两个潜在原因：Visual Studio 选项、或 ReSharper 选项
示例 >：如果我在诸如
Console.WriteLine(myVar.myProp)之类的调用处中断，并且还在myPropgetter 内部中断，内部的断点吸气剂将完全如果以下设置仍然打开，则跳过。对于 Visual Studio 选项：
对于 ReSharper 选项：
因此，请关闭这些功能以避免数据提示导致断点被跳过。
(At least) Two potential causes: Visual Studio options, or ReSharper options
Example: if I break at some call like
Console.WriteLine(myVar.myProp), and I also break inside themyPropgetter, the breakpoint inside the getter will be completely skipped if the following settings are still turned on.For the Visual Studio Options:
And for the ReSharper Options:
So, turn these off to avoid datatips from causing your breakpoints to be skipped.