该断点目前不会被击中。源代码与原始版本不同。这是什么意思?

在Visual Studio中调试时，有时我添加了一个断点，但它是空心的，VS说“断点目前不会被击中。”源代码与原始版本不同。”显然，这使我无法进行调试。

这条消息到底是什么意思?什么原始版本?如果我只是打开了解决方案，而没有对代码做任何更改，又怎么会有“原始版本”呢?

327245 次浏览
小开

你做过这种事吗?

您想继续运行最后一个成功的构建吗?< / >

如果您勾选了方框并按下“是”，即使您的项目没有编译，您也将成功运行最后一个构建。这意味着无论何时设置断点，都将得到该错误。

试着改变这个值:

    <李>工具
      <李>选项
      • 项目和解决方案
        • 构建并运行
          • 在运行时，发生构建或部署错误时:不启动
            • 李< / ul > < / > 李< / ul > < / > 李< / ul > < / > 李< / ul > < / >
小开

如果您使用文件引用二进制文件(而不是项目中代码的项目引用)，并且您引用的编译二进制文件与您机器上相应的源代码不同步，也会经常发生这种情况。这可能是因为您从源代码控制中心下载了一个新版本的二进制文件，而没有附带新的源代码，或者您的机器上有几个版本的二进制文件，并且引用了一个旧的副本，等等。如果这确实是问题所在，那么尽可能多地使用项目参考资料是一个很好的理由。

小开

注意vs中的“Output”窗口，它会告诉你加载了哪些程序集以及何时加载。您可能会看到正在加载文件夹中某个位置的程序集的旧版本。

例如，如果您有多个程序集，并且当前正在尝试插入其中一个支持程序集，CLR将处理程序集解析，这可能会加载您在项目中引用的程序集文件以外的另一个程序集文件。

小开

当调试期间或调试会话之间的系统时间发生变化时，可能会发生这种情况，无论是通过编程方式、手动方式还是通过外部程序。

小开

正如它所说，“源代码与原始版本不同”。

右键单击解决方案资源管理器中的项目文件夹，并选择Clean。构建项目的新版本，断点将再次工作!

小开

如果在“调试”生成配置中未选中DLL项目，你的新代码永远不会被构建!

转到Build --> Configuration Manager ...(在VS2010中)，检查您正在尝试调试的代码的项目是否为当前构建配置进行了检查。

小开

如果您正在使用激活器，而设置断点的程序集尚未加载，则可以获得此消息。

一旦激活器加载程序集(假设程序集和调试符号是最新的)，断点将被解析。查看调试菜单中的模块窗口是一个好地方。在那里您应该寻找您的文件所属的程序集。首先检查程序集是否加载。那么，从哪里装载的呢?然后，是符号文件加载。同样，符号文件从哪里加载?最后检查两者的版本。

小开

去

    <李>工具
      <李>选项
        <李>调试
        • 一般
          • 李< / ul > < / > 李< / ul > < / > 李< / ul > < / >

        取消# EYZ0

小开

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

  • C:\Documents and Settings\%username% AppData\Local\Temp\Temporary ASP。李净文件< /代码> < / > <李> <代码> C: \ windows \ Microsoft.NET \ Framework \ v4.0.30319 \临时ASP。网 李代码文件< / > < / >

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

小开

这也发生在调试一个c++项目时，该项目加载了一个用一些CLR语言(Managed c++， c#等)实现的模块。在这种情况下，错误消息确实具有误导性。

解决方案是将公共语言运行库(CLR)支持配置属性放入启动项目并重新编译。

小开

对我有用的是将解决方案平台从x86改为Any CPU。在更改为Any后，我设置了一个停止地址，运行网站，打开页面，点击按钮，它就停止了。我关闭了网站，改回x86并成功地执行了相同的顺序。

小开

选择< em > < / em >解决方案配置中的调试，而不是释放

菜单截图

小开

我也遇到过这种情况。导致我的问题的条件:

  • 我正在本地运行一个完整的IIS7实例
  • 我正在把我的软件分成不同的项目

我打开以前的版本导致了这个问题(VS提示问我是否想在IIS调试中指向这个实例，我回答'是')，然后打开当前版本(再次响应IIS提示'是')，然后尝试在以前的版本中调试。

为了解决这个问题，我只是关闭并重新打开了之前的预期版本，再次将其断言为调试源。

小开

我最近就遇到了这个问题，在我的案例中，我将这个问题追溯到我在测试时所做的事情:修改系统时间。我并不是说每个人都是这样，但我认为我应该提到它，因为它还没有被提到过。如果你开始在调试构建之间移动时钟，那么它可能会非常困惑，不知道各种文件创建的顺序是什么——我只能假设它使用文件修改日期来确定源代码是否有效，以及需要重新编译哪些二进制文件。

这也是一个重新保存网页的选项。配置以碰撞其修改时间。

小开

尝试在运行调试模式时禁用和重新设置断点，而不是在启动调试模式之前禁用和重新设置断点。

小开

在我的例子中，我在VS 2012中附加了一个正在运行的进程。当附加时，你可以选择以各种模式(本机、脚本、silverlight、托管2.0、托管4.0等)进行调试。默认情况下，调试器自动选择模式。然而，自动并不总是做出正确的选择。如果进程包含多种类型的代码，请确保调试器使用的是正确的代码。

小开

以我为例，我正在开发一个Windows CE应用程序，该应用程序在模拟器上进行测试。问题是可执行文件没有部署到模拟器中，因此.pdb(在开发环境中)与.exe(在模拟器中)不同步，因为新的.exe从未复制到模拟器中。我必须删除模拟器中的.exe，以强制进行新的部署。然后就成功了。

小开

关闭Visual Studio并重新打开解决方案可以修复这个问题，即它是IDE本身的一个bug(我正在运行VS2010)。

如果有多个Visual Studio实例正在运行，则只需关闭运行有问题的解决方案的实例。

小开

在Windows 7, Visual Studio Express 2010下，如果您激活了请使用Windows XP SP3兼容模式选项，则可能会发生此错误。

我取消了这个选项，它再次完美地工作了。右键单击VS或可执行文件的快捷方式，选择属性和兼容性。

小开

code cause

我发现当断点在不能被打断的行上时发生错误。我没有显示工具提示，是为了直接显示后面没有错误的行。

小开

在我的案例中，问题在于ASP。在项目属性>>Web下未启用NET调试

小开

如果您调试的进程包含多个appdomain，并且程序集都被加载到两个域中，其中一个正在加载旧副本(通常是动态加载的插件)，断点可能看起来很稳定，但应该命中断点的线程位于旧程序集的appdomain中，并且从未命中。您可以在模块窗口中看到加载了哪些程序集及其路径。

小开

在我的例子中，我忘记在我声明模板函数的头文件中包含“stdafx.h”。

小开

首先，我尝试从命令行;

从命令行删除临时文件起作用了。

C:\Windows\ Microsoft.NET \ Framework64 \ v4.0.30319 \临时ASP。>rd /s root . NET文件

当我在工具->选项->调试->通用禁用“启用我的代码”选项

我的问题解决。这是一个WCF应用程序，试图调试一个ashx页面。 # EYZ0 < / p >

小开
这发生在我身上是因为我在解决方案中有其他项目没有构建。 在我卸载那些有问题的项目后(在解决方案资源管理器中右键单击项目->卸载项目)，重新构建解决方案并再次运行—断点被击中!< / p >
小开

问题是调试信息与程序集不同步。解决方法很简单:

  1. 转到你的bin文件夹
  2. 删除.pdb文件
  3. 重建

应该能成功!

(奇怪的是，不丢弃.pdb文件的重新构建并不总是有效。我可以看到修改的日期正在更新，但仍然在链的某个地方(VS2013调试器，IIS，程序集缓存)没有检测到此更改)

小开

如果您有解决方案中有多个项目，那么确保将正确的项目设置为StartUp Project。要将特定项目设置为解决方案的启动项目，右键单击该项目，选择Set As StartUp Project。

在我正确地设置我的StartUp项目之后，线程到达了所需的断点。

小开

我之前一直在摆弄我的csproj文件。所以在项目属性(VS 2013) > Web选项卡>服务器部分>[下拉]，我有“IIS快速”选择当我以前有“本地IIS”选择。一旦我将设置修正为之前的设置，断点就可以工作了。

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

中
    <李>解决方案资源管理器
      <李>右键单击解决方案
        <李>属性
          <李>常见的属性
          • 调试源文件
            • "不要找这些源文件"
              • 李< / ul > < / > 李< / ul > < / > 李< / ul > < / > 李< / ul > < / > 李< / ul > < / >

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

小开

检查解决方案中是否有多个具有该名称的文件。

这是我从别人那里接手的一个项目。在Controller.cs中，断点列表充满了行号，有些是活动的，有些不是。我找到了这个问题，并尝试了一些选项，但是当我双击断点时，它们将我带到解决方案中的不同项目。因为文件被称为相同，所以它们看起来是相同的，但实际上不是。答案当然是忽略这个警告，因为如果你要加载另一个文件，它们就会变得活跃。

小开
在某些情况下，重新编译和重新构建并不能帮助克服这个问题。 其他潜在的解决方案之一可能是删除解决方案资源管理器中带断点的源文件，然后重新添加它(例如通过从文件夹中拖放)
小开

对我来说;我的网站在默认网站 (http://localhost/myapp/)下的IIS应用程序中运行，IIS应用程序的映射指向与我正在工作的源代码不同的磁盘路径。

解决;重新映射您的IIS应用程序到与您正在构建的源代码相同的路径。

(如果您在磁盘的不同位置运行同一个应用程序的多个版本，就会发生这种情况)

小开

至:

Tools > Options > Debugging > General > 无节制的 "需要来源 文件完全匹配原始版本"

小开

我只使用重新启动计算机，它对我非常有效。

小开

在我将现有文件添加到项目后，它碰巧在Visual Studio 2017上。这招对我很管用:

  1. 关闭溶液，
  2. 转到SolutionFolder\.vs\SolutionName\v15\sqlite3并删除storage.ide
  3. 再次打开解决方案
小开

从Visual Studio 2017 15.3.1到15.3.5，出现了解决此问题的新方法。如果使用EditorConfig，则charset=utf8选项会导致这些症状。VS团队复制了这个和说他们正在努力。

因此，一个修复方法是注释掉.editorconfig文件中的charset=utf8行。

编辑:这应该在VS 15.5被修复。

小开

我在vs2017的32位版本中遇到过这种情况。

没有一个解决方案对我有效。我重新启动，我清除IDE文件，清洁构建的解决方案，从git回购和重建解决方案无效。

我从nuget中提取了一个64位依赖项，一旦我使用了程序集，源就不再被构建到最终的可执行文件中，而是构建了IDE缓存的源。

我删除了nuget配置，删除了引用的程序集，下载了源代码，手动构建log4net，对其进行了签名，将其添加到我的项目中的一个文件夹中，并对其添加了引用，然后我就可以再次进行调试了。

这是一个痛苦，我希望它能出现在答案列表中，让所有人都看到。

编辑:在构建过程中没有错误，尽管在IDE设置中打开了“构建错误提示”选项。

小开
对我来说，解决方案隐藏在项目属性的Advanced Build Settings中: # EYZ0 < / p >

由于未知的原因，它被设置为none:设置为full会导致断点被击中。

要进入这个对话框，请打开项目属性，然后转到Build，然后选择页面底部的Advanced...按钮。

小开

在尝试调试时，请确保您没有处于发布模式。

小开

此外，VS 2017的一些版本(结合.editorconfig)也有一个问题:从15.3开始，当文件的字符集与.editorconfig (utf8或utf8-bom)中的字符集不相同时，断点将不起作用。

小开

对我来说，没有一个项目能解决这个问题。我只是在函数中添加了一行新代码，类似于:

int a=0;

通过添加这个，我想我触发了visual studio在原始版本中添加这个功能

小开

也许dll是从GAC加载的。

您可以从gac卸载dll，需要管理员权限。

gacutil -u YourDll

小开

我在一个分层架构项目的几个项目中遇到了同样的问题，问题是在配置中，所选项目的构建复选框没有被选中。所以这个问题在一个项目中得到了解决。

对于另一层，即使在配置中启用了构建，它也会带来同样的麻烦。我做了所有其他的选择，比如重新开始清理项目，但没有一个有用。最后，我取消了该特定项目的build复选框，并进行了清理和重建。他们再次标记了复选框，并照做了 相同的。

.

.

希望这能有所帮助。

小开

对于VS Code用户:

如果您在调试ASP . net Core应用程序时碰到了这个选项，请确保在tasks.json中定义的构建任务和在调试控制台窗格中可以看到的输出成功运行。

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

小开

有意地中断构建，这意味着在项目中添加一些调试时不同步的任意文本。尝试调试并接收异常。现在修复异常并调试项目。

小开

在我的例子中，其他建议都不起作用，但是重新克隆我的存储库使这个问题消失了。

小开

我在将一个项目从netcoreapp2.0升级到netcoreapp2.2后遇到了这个问题。

我只是通过编辑.csproj文件中的TargetFramework条目来做到这一点，而忽略了对launch.json进行更改。

"program": "${workspaceFolder}/src/MyProject/bin/Debug/netcoreapp2.0/MyProject.dll"

这意味着VS Code总是加载旧的2.0版本的项目。我在删除/bin和/obj中的所有内容后才发现它，然后它根本不会运行，直到我在上面的路径中发现2.0。

小开

我遇到了这个问题，这是因为我们的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"/>-->
小开

我在VSCode中遇到了这个问题，问题是我在编辑器中看到的文件与项目正在构建的文件的副本不相同。我将一个c#库的存储库克隆到两个位置，一个在编辑器中打开，另一个由项目链接。如果清洁建筑不适合你，请检查你在编辑器中查看的文件副本是否正确!

小开

在我的例子中，我被分配了大约120kb的base64值给静态类中的静态约束字符串字段。之后出现了这个问题。我尝试了很多解决方案，但问题没有解决，直到我把这个沉重的任务。

< p >我的环境: MS VS Community 2017 版本15.9.16 < / p >
小开

我在使用本地IIS而不是IIS express时遇到了这个问题。IIS中的文件源确实与Visual Studio中的文件源相匹配，但是，我不得不在IIS中回收应用程序池，以便让它使用新构建的dll。

小开

帮助我的步骤(VS Community 2017, 15.9.11)。

请注意，执行以下步骤后将丢失断点。

  1. 右键单击类文件
  2. 已选排除 李项目< /强> < / >
  3. 右键单击该项目
  4. 选择添加和现有的文件
  5. 导航到选择相关的类文件
小开

我通过首先删除有问题的文件来解决这个问题。

编译。

出于某种原因，程序还是会运行。它不应该编译。它有错误之类的，但还是能运行。

我读了有问题的文件。再次运行。不知怎的，它自己固定了。

小开

因为构建版本更改了(很可能您修改了源代码)，所以重新编译解决方案并再次运行应用程序，之后它将到达调试断点。

小开

我的问题有点愚蠢。我有两份我的项目副本，我在visual studio中混合文件。

假设你有projectX和projectY。这些项目都包含myFile.cs。打开projectX，编辑myFile.cs。但是这个myFile.cs属于projectY。(可以在visual studio中打开来自不同项目的文件)所以在这种情况下，警告说源代码将不同于原始。

小开

我只是重新装填，清理和重建我的作品。

小开

我已经试过提出的解决办法了，但不管用。

如果您有多个项目，请将要调试的项目作为启动项目。

enter image description here

小开

我在VS2019中遇到了这个错误，我认为当Windows的时钟改变时就开始出现这个错误。

小开

退出VS. ->删除。vs文件夹。→开放VS. ->运行项目。

上述解决方案对我很有效。希望这也能对你有所帮助。

小开

有时你只需要将解决方案配置从“发布”更改为“调试”

小开

它工作得很好-你必须在复选框中选择“启用“我的代码”"如下图所示:

enter image description here

小开

尽管所有的答案，我的问题实际上不同于这里提到的!

确保您的属性->构建tab ->输出路径指向您所选择的构建配置的解决方案中所有其他项目的相同位置!

enter image description here

如果你的启动项目将它的可执行文件从你试图调试的dll发送到不同的文件夹，你可能会遇到问题，尽管你的构建和visual studio工作完美。

小开

对于一个类似的问题，我做了如下处理:

取消选中“Enable Just My code”选项;从菜单Debug >选项→一般

小开

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

我有一个主项目引用项目xxx.dll

. dll中的断点未被击中

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

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

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

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

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

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

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

小开

确保<Optimize>false</Optimize>在csproj中设置为false


提交答案