断点无法绑定-Visual Studio 2015

我刚刚从Visual Studio 2013升级到2015，现在遇到断点问题。

断点实际上是有效的选择，如果我在调试时设置了一个，则会收到错误消息：

断点绑定失败。

任何帮助，将不胜感激。我准备放弃2015年并回去。

我有相同的问题，但解决方案不同。请注意，我已更新到VS 2015 Update 1，问题仍然存在。

在VS的早期版本中，启动调试会自动在调试模式下触发构建。但是VS2015却没有。

因此，如果您的上一个版本处于发布模式，并且尝试调试，则断点将不起作用。

您必须先在调试模式下手动构建，然后再开始调试。

我有同样的问题。

我解决了它，在项目属性“构建”选项卡中禁用了“优化代码”选项。

这看似微不足道，但经过与您提到的相同的问题进行了很多努力之后，我发现在尝试调试时，我的构建设置为“发布”而不是“调试”。.重新构建“调试”的解决方案”修复它，我可以像往常一样设置断点

我遇到了类似的问题，即断点无法绑定，以及某些局部变量未在“本地”窗口中求值。最终解决的问题是在“选项”->“调试”->“常规”选项卡中启用了“抑制模块负载上的JIT优化（仅受管理）”选项。一旦设置好，它就可以毫无问题地绑定了。

我有这个问题。我运行了一个性能分析会话，该会话Web.config使用性能监视器的设置修改了文件：

<appSettings>
   <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>


<compilation debug="true" targetFramework="4.5" 
      assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
   ...
</compilation>


<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
         <assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
      </dependentAssembly>
      <dependentAssembly>
         <assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
      </dependentAssembly>
   </assemblyBinding>
</runtime>

这破坏了我在断点处停止的能力。当我恢复到原始的Web.config（删除了Performance Profiler设置）时，断点再次开始工作。

我昨天有同样的问题。我使用了“清洁解决方案”功能，它很有帮助。

解决方案是禁用设计优化。

Project Properties> Build> Advanced Compile Options> Enable Optimizations

我在解决方案上运行性能，并将其添加到我的web.config中

<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> 

在assemblyPostProcessorType的问题，我删除了它，这解决了我的问题

将Release模式更改为Debug，就我而言，这解决了我的问题。

我没有更改“优化”设置，但根据此处的其他答案，我

1. 将解决方案资源管理器设置为显示项目的所有文件
2. 删除隐藏的bin和debug文件夹
3. 对项目执行“清洁”
4. 在项目上执行了“重建”

到目前为止，这已经为我解决了。好像更新到VS2015 Update 2似乎使我的系统有些不适。

我知道这是一篇过时的文章，但是如果上述所有其他技巧都无法解决，请确保要调试的映像是最新的。出于某种原因，在将.NET Core项目发布并传输到RPi上的Raspberry Pi'unzip'之后，并没有复制和覆盖工作目录中的某些DLL。当我连接调试器时，认为一切正常，一些断点被命中，另一些断点未命中，而另一些则给我“无法绑定”错误。解决解压缩问题后，所有断点和符号都会恢复。我希望这有帮助。

我今天遇到绑定断点错误。我已经解决了我做下面的问题。

如果所有调试配置均不正确，则无法通过以下方法解决问题。

1. 清洁项目
2. 如果输出路径与bin文件夹不同，则将其替换为bin文件夹（这是最重要的规则）
3. 重建

也许此解决方案可以帮助某人。

VS断点无法在异步方法上绑定。

我安装了导致此问题的App Dynamics代理。删除它，您就可以开始了。

我遇到了同样的问题，但是还没有意识到调试工具栏上的“调试”已更改为“发布”（通常直接在菜单下）。所以我将其设置为“ Debug”，它起作用了。

Microsoft Visual Studio 2015更新3的新更新（KB3165756）已为我解决了断点问题，在这里我试图检查ASP.NET Core应用程序中cshtml文件中嵌入的C＃代码中的局部变量。

步骤1，排除明显的问题：

• 在调试模式下编译。
• 设置断点之前，请尝试清洗溶液。
• 转到Debug文件夹，然后删除[您的应用程序] .pdb文件。
• 然后执行“构建或重建”应用程序。
• 转到Debug文件夹，并确认您有一个全新的[您的应用程序] .pdb文件。
• 然后尝试设置您的断点。

步骤2对于C ++项目：

检查以下项目属性：

• C ++ / General / Debug信息格式：程序数据库。
• C ++ /优化：禁用。
• C ++ /代码生成/运行时库：多线程调试。
• 链接器/调试/生成调试信息：是。
• 链接器/调试/生成程序数据库：$（TargetDir）$（TargetName）.pdb。
• 链接器/清单文件/生成清单：否。
• 链接器/清单文件/允许隔离：否。
• 链接器/嵌入式IDL /忽略嵌入式IDL：是。

• 再次执行步骤1

  您可以尝试添加__debugbreak（）。该语句需要放在要中断的源文件中。

步骤2对于C＃项目：

• 在项目属性中，应禁用“构建/常规/优化”代码。
• 在IDE设置中调试/选项和设置/调试/常规禁止在模块加载时进行JIT优化（仅受管理）：已启用
• 再次执行步骤1

尝试在另一台计算机上打开解决方案。如果可以在其他计算机上绑定断点，则可能意味着VS或OS存在问题。

步骤3，确保您的VS是最新的：

在VS2013 RTM以及VS2015 Update 1和Update2中已经有关于此类问题的报告。

在VS中，转到“工具/扩展和更新/更新/产品更新”，然后查看运行的版本。如果需要更新，它将显示在此处。

步骤4，确保您的操作系统是最新的：

最后，如果您运行的是Win 10操作系统，则在版本14251中存在关于此问题的已报告错误。在版本14257（及更高版本）中已解决。

我只是遇到了类似的问题，而这里的答案都没有解决我所面临的问题。但是，与问题不同，我从未收到任何消息说绑定失败。断点永远不会命中。希望这对将来使用WCF砸墙的人有所帮助。

TL / DR：
在SOAP消息中，有一条记录包含错误数据，导致断点未命中。

全文：

我有另一个团队的基于WSDL的WCF服务。不是我的定义，对此没有控制...通过此服务，我从另一个团队收到消息。以我为例，我可以接收消息，可以将消息记录到数据库中的消息日志表中（发生在调用我的service方法之前），看似调用了service方法（也许不是），并且服务器以a 202已接受。通信正常，但在方法调用期间没有数据保存到数据库中。

由于该服务返回了成功响应，因此我排除了http和传输相关的问题。

所以我启动了VS2015来调试服务。所讨论的消息很大，但完全在我期望的范围之内。我在服务方法的第一行上放置了一个断点，并通过它发送了大消息，但断点从未命中。我尝试了一条较小的消息，我知道它可以在相同的运行实例上工作，并且断点恰好被击中。因此，配置中的所有内容似乎都很好。我以为邮件大小可能有问题。

我尝试了所有可以找到的一切-确保我处于调试配置中，清理并重建，将调试器手动附加到w3wp进程（VS已经存在），Debugger.Break()而不是使用断点，设置多个启动项目，卸载测试项目因此，该服务项目是唯一的项目，即更新.NET，重新启动VS2015，重新启动，从本地IIS切换到IIS Express并再返回，并使用保证的最新WSDL重新创建服务。没关系 断点从未被击中。

我最终不得不一遍又一遍地清除大消息中的记录，直到找到一条包含不良数据的单条记录。在我的情况下，这是一条记录，对于2个DateTime字段没有任何价值。当我创建一条仅包含一条记录的消息并将其发送时，断点没有被命中。当我为这2个DateTime字段提供值并在断点处按预期发送相同（固定）消息时。

我启用了每个CLR异常，除了丢失的.pbd文件（我不在乎）之外，什么也没有触发。WCF高兴地发送了一个错误记录的请求。我并不是说WCF不应根据合同将其发送出去，仅是因为不良记录导致未命中断点。

我必须修改web.config文件才能启用调试。更改此：

<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

至：

<compilation debug="true"/>

在尝试其他解决方案之前，请先清洁整个解决方案。在尝试了先前答案中提到的几乎所有其他内容，并重新启动了Visual Studio几次之后，仅清洁解决方案就可以解决问题！

我尝试了这里建议的一切。最终，我在项目属性-> Web中将“特定页面”设置为本地的起始URL，页面和查询参数。在调试模式下进行了清理和重建，结果达到了我的断点。

虽然这是一个较晚的版本（VS2017），但C＃项目遇到了这个问题。尝试清洁，重建，重新启动Visual Studio等。

解决的问题是关闭Visual Studio并删除.vs文件夹，该文件夹是解决方案目录中的隐藏文件夹。删除.vs文件夹应该不会给您带来任何问题，尽管您将需要重置启动项目。

就我而言，我使用后创建了一个新的web.config文件Profiler。将web.config还原到以前的版本可以解决此问题。这是一个VS2015 C＃Web应用程序。

如果您发布的Web应用程序检查Configuration设置为Debug（默认情况下，调试配置中设置为未优化代码且完全创建符号表）。

我看着前面的答案，@威尔的answear固定我在的主要问题，另一个是能够编辑和继续，但服用仔细看看AssemblyInfo.cs文件，我发现了一些调试功能残疾人所在。

然后我最终删除了旧的调试属性，并添加了我从另一个项目中获得的以下内容

#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endif

但是我觉得这不是最好的方法。