在 VS.Net 2005 中调试时断点未连接
最近遇到这个问题...在 VS.Net 2005 中调试应用程序时，断点未连接。 错误表示编译的代码与运行的版本不一样，因此存在不匹配导致断点断开。
清理所有 bin 文件的解决方案并重新编译没有帮助。 也不只是发生在单个盒子或人身上。
添加注释： 此解决方案位于 TFS for Source Control 中。 如果我删除本地 TFS 存储库并从头开始从源代码管理中获取它，有时问题就会消失。 我还尝试卸载并重新安装 Visual Studio。 这有时也有帮助。 事实上，这两种方法有时都能起作用，这表明问题不是由其中任何一种直接引起的。
Been running into this problem lately... When debugging an app in VS.Net 2005, breakpoints are not connected. Error indicates that the compiled code is not the same as the running version and therefore there's a mismatch that causes the breakpoint to be disconnected.
Cleaned solution of all bin file and re-compile doesn't help. Not just happening on a single box or person either.
Added Note:
This solution is in TFS for Source Control. If I delete my local TFS repository and get it from source control from scratch, SOMETIMES the problem goes away. I've also tried un-installing and re-installed Visual Studio. That also SOMETIMES helps. That fact that both of those work some of the time indicates that the problem isn't caused by either directly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
也许这个建议可能会有所帮助：
我发现有时需要：
资料来源： 当前不会命中断点。 该文档尚未加载任何符号。
Maybe this suggestion might help:
I've found that it's sometimes necessary to:
Source: The breakpoint will not currently be hit. No symbols have been loaded for this document.
http://dpotter .net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/
http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/
在选项-> 调试时您可以取消选中“要求源文件与原始版本完全匹配”，这可能会有所帮助。
In Options -> Debugging you can uncheck "require source files to exactly match the original version", which may help.
构建配置是否设置为“Release”？
您是否有对设置断点的外部 DLL 的引用？
Is the build configuration set to Release?
Do you have a reference to an external DLL where the breakpoint is set?
您是否正在创建一个由外部可执行文件使用的 DLL 项目？ 您使用的是 .NET 还是 COM？
如果您将 COM Interop 与 .NET 一起使用，则当可执行文件加载 DLL 时，DLL 版本有时可能会出现问题。 例如，如果您的日常构建产生递增的构建号，但您的调试 DLL 具有较小的构建号，则可执行文件将不会加载调试 DLL。 要解决此问题，您需要扫描注册表中的 HKEY_CLASSES_ROOT\CLSID 目录以查找 .NET/COM 组件的 GUID/CLSID。 在 InProc32 下，删除版本号高于调试 DLL 的条目。
同样，上述内容仅适用于 .NET + COM Interop DLL。
Are you creating a DLL project that is consumed by an external executable? Are you using .NET or COM?
If you are using the COM Interop with .NET, the DLL versions can sometimes be a problem when the executable loads the DLL. For instance, if your daily build cranks out an incrementing build number but your debug DLL has a smaller build number, the executable won't load the debug DLL. To fix this, you will need to scan the HKEY_CLASSES_ROOT\CLSID directory in your registry for the GUID/CLSID of your .NET/COM component. Under InProc32, delete entries with a higher version number than your debug DLL.
Again, the above only applies to .NET + COM Interop DLLs.
我过去也遇到过类似的问题。
通过关闭 Visual Studio 并删除“C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files”下为该项目生成的临时 ASP.NET 程序集文件，然后重新打开该项目，可以解决该问题。
阅读 在此处发布 以及解决该问题的评论。
I've had a similar problem in the past.
It was solved by closing Visual Studio and deleting the temporary ASP.NET generated assembly files for the project under "C:\WINDOWS\Microsoft.NET\Framework{framework version}\Temporary ASP.NET Files", re-opening the project.
Read the post here and the comments to resolve it.
AviewAnew - 已经应 MS 技术人员的要求做到了这一点。 取消选中需要源文件来匹配版本没有帮助。
Mike L - 配置设置为“调试”，现在有外部 DLL。 使用除框架引用之外的所有本地项目。
AviewAnew - had already done that at the request of the MS tech person. It didn't help to uncheck require source file to match version.
Mike L - configuration is set to DEBUG and there are now external DLL. Using all local projects except framework references.
您确定 .pdb 文件与您正在运行的可执行文件位于同一文件夹中吗？ 确保两个文件的最后修改日期匹配，并且 VS 附加到该 exe（而不是其他）。
Are you sure the .pdb files are in the same folder as the executable you are running? Make sure the last modified date of both files match, and that VS is attached to that exe (and no other).
您是否有一个构建后步骤以任何方式影响您的二进制文件？ 如果是这样，这可能会使调试器感到困惑，并使其看起来像您的符号与您的 exe/dll 不匹配，因为大小/时间戳不正确。
Do you have a post build step that touches your binaries in any way? If so, this can confuse the debugger and make it look like your symbols don't match your exe/dll because of the incorrect size/timestamp.
过去，我有时发现关闭编译器优化可以解决“丢失”断点的问题，因为优化器（正确地）确定代码没有被调用，并将它们从编译版本中删除。
这听起来确实是一个不同的问题，但可能值得确保在调试模式下关闭优化。 [项目/属性，构建设置选项卡]
In the past I have sometimes found that switching off compiler optimisations can solve 'missing' breakpoints, as the optimiser had determined (correctly) that the code was not being called, and removed them from the compiled versions.
This does sound like a different issue, but it might be worth making sure that optimisation is switched off in Debug mode. [Project / Properties, Build settings tab]
确定在应用程序的任何点上，代码上都没有阻止代码被调试的调试属性（例如 DebuggerHidden 或 DebuggerStepThrough）吗？
Sure there are no Debug attributes on the code that prevent code from being debugged, such as DebuggerHidden or DebuggerStepThrough, at any point of the application?
您能否单步执行代码直至断点所在行，而不是运行并等待断点命中？ 您能单步执行代码吗？
Can you step through your code up to the line of the breakpoint instead of running and waiting for it to hit? Can you step through code at all?