至:

Tools > Options > Debugging > General > unchecked "要求源 文件与原始版本完全匹配”

对我来说，那是在做一个网站项目的时候。在清理了这些临时文件夹后，我得到了正确的编译器错误:

C:\Documents and Settings\ %username%\AppData\Local\Temp\临时 ASP。网络文件 C: \ windows \ Microsoft.NET \ Framework \ v4.0.30319 \临时ASP。网 文件

我最终解决了这个问题，当我发现一个类文件，我故意移动到一个子文件夹，以某种方式重新出现在根文件夹。当我在编辑另一个的时候，VS用了那个。

对于VS Code用户:

如果在尝试调试ASP . net Core应用程序时遇到此问题，请确保在tasks中定义构建任务。json，并且您可以在调试控制台窗格中看到其输出，则成功运行。

在启动中定义的调试配置。引用此任务的Json将出于某种原因(至少在某些情况下)继续执行定义的二进制文件，即使构建任务失败，并且由于构建任务失败，该二进制文件将成为最后一个成功构建的程序集。

我遇到了这个问题，这是因为我们的DevOps团队要求Azure云设置。在开发时，只需将其从Web.config中删除。

<httpRuntime maxRequestLength="102400" />

    <!--TODO #5 comment out for IIS Express fcnMode goes with httpRunTime above in other environment just in DEV -->
    <!--fcnMode="Disabled"/>-->

在我的案例中，是项目/属性/构建选项卡中的错误设置

我有一个主项目引用项目xxx.dll 引用dll中的断点未被命中。

对dll的引用被设置为库文件夹中的bin\debug\xxx.dll

因此，当我调试主项目时，它会到库的bin\debug文件夹中寻找xxx.dll。

但是，在库的属性中，由于一些黑暗的原因，输出路径被设置为bin\x86\debug而不是bin\debug

因此，库的每次构建都将新的dll放在bin\x86\debug文件夹中，而不是在bin\debug中

所以VS在调试的时候总是找到一个旧的库的dll，因此错误是正确的，有一个不同的源。

所以我修正了从库到bin\debug的输出路径，所以主项目的引用现在会找到正确的版本，现在我的断点再次被击中。

我花了好几个星期才弄明白

有一个几乎察觉不到的设定为我解决了这个问题。 如果有一个特定的源文件没有命中断点，则可以将其列在

解决方案资源管理器 右键单击解决方案 属性 公共属性 调试源文件 "不要找这些源文件"

出于某种我不知道的原因，VS 2013决定在那里放置一个源文件，随后，我无法在该文件中点击断点。这可能是“源代码与原始版本不同”的罪魁祸首。