最近一直遇到此问题...在VS.Net 2005中调试应用程序时，未连接断点。错误表明编译的代码与运行的版本不同，因此存在不匹配导致断点断开的情况。

清理所有bin文件并重新编译的解决方案无济于事。不仅发生在单个盒子或者一个人身上。

补充说明：
此解决方案在TFS中用于源代码管理。如果我删除本地TFS存储库并从头开始从源代码管理中获取它，有时问题就会消失。我也尝试过卸载并重新安装Visual Studio。这有时也会有所帮助。两者有时都起作用的事实表明，问题并不是由任何一个直接引起的。

解决方案

在选项->调试中，我们可以取消选中"需要源文件以完全匹配原始版本"，这可能会有所帮助。

构建配置是否设置为"发布"？

我们是否引用了设置了断点的外部DLL？

AviewAnew已应MS技术人员的要求进行了此操作。取消选中要求源文件以匹配版本并没有帮助。

Mike L配置设置为DEBUG，现在有外部DLL。使用除框架引用以外的所有本地项目。

我们确定.pdb文件与正在运行的可执行文件位于同一文件夹中吗？确保两个文件的最后修改日期匹配，并且VS添加到该exe(并且没有其他添加)。

我们是否正在创建由外部可执行文件使用的DLL项目？我们使用的是.NET还是COM？

如果将COM Interop与.NET一起使用，则当可执行文件加载DLL时，DLL版本有时可能会成为问题。例如，如果日常构建启动了递增的内部版本号，但是调试DLL的内部版本号较小，则可执行文件将不会加载调试DLL。若要解决此问题，我们将需要在注册表中的HKEY_CLASSES_ROOT \ CLSID目录中扫描.NET / COM组件的GUID / CLSID。在InProc32下，删除版本号高于调试DLL的条目。

同样，以上内容仅适用于.NET + COM Interop DLL。

我们是否有一个构建后步骤可以以任何方式触及二进制文件？如果是这样，这可能会使调试器感到困惑，并由于大小/时间戳错误而使符号看起来与exe / dll不匹配。

在过去，我有时发现关闭编译器优化可以解决"丢失"的断点，因为优化器已经(正确地)确定未调用代码，并将其从编译版本中删除。

这听起来确实是一个不同的问题，但是可能值得确保在"调试"模式下关闭优化。 [项目/属性，构建设置选项卡]

过去我也遇到过类似的问题。

通过关闭Visual Studio并删除该项目在" C：\ WINDOWS \ Microsoft.NET \ Framework {框架版本} \ Temporary ASP.NET文件"下的临时ASP.NET生成的程序集文件，重新打开该项目，可以解决该问题。

在此处阅读帖子和评论以解决该问题。

确保在应用程序的任何位置，代码上都没有阻止调试代码的Debug属性，例如DebuggerHidden或者DebuggerStepThrough。

我们是否可以单步执行代码直到断点所在的行，而不是运行并等待其命中？我们完全可以单步执行代码吗？

也许这个建议可能会有所帮助：

• 在Visual Studio中进行调试时，单击"调试">" Windows">"模块"。 IDE将停靠"模块"窗口，显示已为项目加载的所有模块。
• 查找项目的DLL，然后检查它的符号状态。
• 如果显示"已加载符号"，则说明我们是黄金。如果显示"找不到或者打开PDB文件"之类的内容，请右键单击模块，选择"加载符号"，然后浏览至PDB的路径。

我发现有时需要执行以下操作：

• 停止调试器
• 关闭IDE
• 关闭托管应用程序
• 核对obj和bin文件夹
• 重新启动IDE
• 重建项目
• 再次通过"模块"窗口
• 浏览到PDB文件的位置后，"符号状态"应更改为"已加载符号"，现在，我们应该可以在代码行中设置和捕获断点了。

来源：断点当前不会被命中。没有为该文档加载任何符号。

http://dpotter.net/Technical/2009/05/upgrading-to-ie8-breaks-debugging-with-visual-studio-2005/