ブレークポイントがバインドに失敗しました-Visual Studio 2015

158

Visual Studio 2013から2015にアップグレードしたところ、ブレークポイントで問題が発生しました。

これは、ブレークポイントが実際に機能するヒットまたはミスであり、デバッグ中に設定すると、エラーが発生します。

ブレークポイントはバインドに失敗しました。

任意の助けいただければ幸いです。私は2015年をあきらめて、戻る準備ができています。

c#  visual-studio  visual-studio-2013  visual-studio-2015  breakpoints 
— シーラー_05
ソース

回答:

226

私は同じ問題を抱えていましたが、解決策は異なりました。VS 2015 Update 1に更新しましたが、問題はまだ残っています。

VSの前のエディションでは、デバッグを開始すると、デバッグモードでビルドが自動的にトリガーされました。しかし、VS2015ではそうではありません。

したがって、最後のビルドがリリースモードでデバッグを試みた場合、ブレークポイントは機能しません。

最初に手動でデバッグモードでビルドしてから、デバッグを開始する必要があります。

— マックスファビリ
ソース
3
これは奇妙な行動ではありませんか？バグと見なすことができますか？
— Tolga Evcimen
Microsoft Visual Studio 2015 Update 3（KB3165756）の更新プログラムをインストールすると、以前に「ブレークポイントがバインドに失敗しました」と表示されていたデバッグの問題が修正されました。C＃ビューのエラー
— ヘム
2
これは実際に良かった:)リリースビルドがアクティブであるのを忘れて、これを読んでデバッグバックをアクティブにしてすべてが「正常」になるまで、非常に奇妙なデバッグセッションが発生していました。
— スペーサーを2016
1
私は奇妙な経験をしました。ビルドを「リリース」、ビルド、「デバッグ」の順に設定して、再度ビルドする必要がありました。
— samneric 2017年
@TolgaEvcimen VS 15.5.6の時点で2年以上経過しても動作は同じであることを考えると、MSはそれをバグとは見なしていません。個人的には、デバッグビルドを自動的にトリガーするという古い動作に戻す方がより論理的だと思います。または、少なくとも警告を出します。
— Max Favilli 2018
82

私も同じ問題を抱えていました。

プロジェクトプロパティの[ビルド]タブの[コードの最適化]オプションを無効にすることで解決しました。

— Edu_LG
ソース
問題はまだ私のプロジェクトの1つに戻ってきました。とにかく、Update 1では、今までのようにうまくいけば、そのクリーンのすべて出ているvisualstudio.com/en-us/news/vs2015-update1-vs.aspx
— Sealer_05
2
それがデバッグビルドの要点ではありませんか？「最適化コード」をオフにしたリリースビルドはお勧めしません。
— Bart Friederichs
構成マネージャーを確認したところ、ソリューションをデバッグに切り替えたところ、一部のプロジェクトが誤ってリリースに設定されていました。つまり、ドロップダウンで[デバッグ]を選択すると、それらのプロジェクトでリリース構成が使用され、最適化されます。
— AaronLS
39

これはささいなことのように思えるかもしれませんが、あなたが言及したのと同じ問題を何度も繰り返した後、私がデバッグしようとしたときに、ビルドが「デバッグ」ではなく「リリース」に設定されていることがわかりました。「デバッグ」のソリューションを再ビルド"修正し、ブレークポイントを通常どおりに設定できました

— ケネス・モラー
ソース
2
これでブレークポイントを設定することができましたが、永遠に続くわけではありません。また、コードのランダムな行をスキップしてもデバッグの問題がまだあります
— Sealer_05
この問題は、非常に異なるソリューションの成功についての一時的な報告がすべてあったとしても続きます。ただし、この「修正」は、「コンピュータが接続されているか」と並べて行う必要があります。それは本当に解決策ではありません。はい、パワーは必要ですし、リリースビルドでブレークポイントを設定することはできません-geez。
— Rick O'Shea、2017年
@KennethMøllerご指摘のとおり、些細なことのように見えるかもしれませんが、私の問題も解決しました。
— ベンジュニア
36

バインドに失敗するブレークポイント、および[ローカル]ウィンドウで評価されない特定のローカル変数に関する同様の問題がありました。最後に修正されたのは、[オプション]-> [デバッグ]-> [一般]タブの[モジュールのロード時にJIT最適化を抑制する（管理のみ）]オプションを有効にすることでした。一度設定すると問題なくバインドできました。

— 意志
ソース
私はそれを試してみましたが、私のAPIコントローラーでブレークポイントをまだヒットしていませんでした。
— Sealer_05 2015
— Nathan
ええと、いいえ、これは解決策ではありません。私たちが得ているのは、問題に関係のないスイッチングをランダムに微調整している人々です。それは自然に消えるようです
— Rick O'Shea
最後に。これにより、以前にジャンプしていたコードをステップスルーすることもできました。
— ジェフデイビス
これはVS 2019で私のためにそれを解決しました、どうもありがとう！
— EM0
14

私はこの問題を抱えていました。パフォーマンスプロファイリングセッションを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に戻した（パフォーマンスプロファイラーの設定を削除した）と、ブレークポイントが再び機能し始めました。

— Allbite
ソース
1
これは、VS 2017でプロファイリングした後の解決策でした。
— Lee Taylor
1
ブレークポイントがバインドに失敗する原因はたくさんあるようですが、これは私たちが見たものです。
— BJury 2018年
2
これで終わりです。私はこのAppSettingを削除しました：<add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Team Tools\Performance Tools\vsinstr.exe"/>
— Chad Hedgcock '25年
5

昨日も同じ問題がありました。「クリーンソリューション」機能を使用しました。

— カーネルデバッガ
ソース
3
それはコメディの中心のようなものです。「ラバーチキンをマシンにかざしてうまくいった」を待っています この問題を経験した開発者は6数人いますが、これらのアドホックな説明のない特別なソリューションは機能しません。
— Rick O'Shea 2017年
5

解決策は、設計の最適化を無効にすることです。

Project Properties> Build> Advanced Compile Options> Enable Optimizations

— ちうちフリオ
ソース
4

私は自分のソリューションでパフォーマンスを実行し、それが私の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が問題です、私はそれを削除し、それが私の問題を解決しました

— Xszaboj
ソース
1

「最適化」設定は変更しませんでしたが、ここでの他の回答に基づいて、私は

  1. プロジェクトのすべてのファイルを表示するようにソリューションエクスプローラーを設定する
  2. 非表示のビンとデバッグフォルダーを削除しました
  3. プロジェクトで「クリーン」を実行しました
  4. プロジェクトで「リビルド」を実行しました

これまでのところ、これで解決しました。VS2015 Update 2にアップデートすると、システムにいくつかの問題が生じたようです。

— louisik1
ソース
1

私はこれが古い投稿であることを知っていますが、上記の他のすべてのトリックがうまくいかない場合は、デバッグしようとしているイメージが最新のものであることを確認してください。何らかの理由で、.NET Coreプロジェクトを公開してRPi上のRaspberry Piの「unzip」に転送した後、作業ディレクトリ内の一部のDLLがコピーおよび上書きされませんでした。すべて正常であると考えてデバッガーをアタッチすると、いくつかのブレークポイントがヒットし、他のブレークポイントはヒットせず、一部のブレークポイントで「バインドできません」エラーが発生しました。解凍の問題を解決すると、すべてのブレークポイントとシンボルが戻ってきました。これがお役に立てば幸いです。

— ブライアン・クレバー
ソース
0

今日、バインディングブレークポイントエラーが発生しました。そして、私は下をやっている私の問題を解決しました。

すべてのデバッグ構成が正しくない場合、以下を実行して問題を修正することはできません。

  1. クリーンプロジェクト
  2. 出力パスがbinフォルダーと異なる場合は、binフォルダーに置き換えます（これは最も重要なルールです）
  3. 再構築

多分この解決策は誰かを助ける。

— RockOnGom
ソース
0

VSブレークポイントは非同期メソッドにバインドできません。

これを引き起こしたApp Dynamicsエージェントをインストールしました。それを削除し、あなたは行ってもいいです。

— ダニ
ソース
0

私も同じ問題を抱えていましたが、デバッグツールバー（通常はメニューのすぐ下）で "Debug"が "Release"に変更されたことに気づきませんでした。だから私はそれを「デバッグ」に設定しました。

— ジャレッド・マックラッケン
ソース
0

ステップ1、明白なものを除外する：

  • デバッグモードでコンパイルします。
  • ブレークポイントを設定する前に、ソリューションをクリーンアップしてください。
  • Debugフォルダーに移動し、[Your application] .pdbファイルを削除します。
  • 次に、アプリケーションをビルドまたは再ビルドします。
  • Debugフォルダーに移動して、新しい[Your application] .pdbファイルがあることを確認します。
  • 次に、ブレークポイントを設定してみてください。

ステップ2 C ++プロジェクトの場合：

次のプロジェクトプロパティを確認します。

  • C ++ /全般/デバッグ情報フォ​​ーマット：プログラムデータベース。
  • C ++ /最適化：無効。
  • C ++ /コード生成/ランタイムライブラリ：マルチスレッドデバッグ。
  • リンカー/デバッグ/デバッグ情報の生成：はい。
  • リンカー/デバッグ/プログラムデータベースの生成：$（TargetDir）$（TargetName）.pdb。
  • リンカー/マニフェストファイル/マニフェストの生成：いいえ。
  • リンカー/マニフェストファイル/分離を許可：いいえ。
  • リンカー/埋め込みIDL /埋め込みIDLを無視：はい。

  • 手順1をもう一度実行します

    __debugbreak（）を追加してみてください。このステートメントは、中断するソースファイルに挿入する必要があります。

ステップ2 C＃プロジェクトの場合：

  • プロジェクトのプロパティで、ビルド/一般/最適化コードを無効にする必要があります。
  • IDE設定Debug / Options and Settings / Debugging / General Suppress JIT optimization on module load（Managed only）：Enabled
  • 手順1をもう一度実行します

別のマシンでソリューションを開いてみてください。別のマシンにブレークポイントをバインドできる場合は、VSまたはOSに問題があることを意味します。

ステップ3、VSが最新であることを確認します。

VS2013 RTMとVS2015 Update 1およびUpdate2で​​は、このような問題が報告されています。

VSで、Tools / Extensions＆Updates / Updates / Product Updatesに移動し、実行しているバージョンを確認します。更新が必要な場合は、そこに表示されます。

ステップ4、OSが最新であることを確認します。

最後に、Win 10 OSを実行している場合、ビルド14251に存在するこの問題に関して報告されたバグがありました。これは、ビルド14257（およびそれ以上）で解決されました。

— メラフコチャビ
ソース
0

私は似たような問題に遭遇しましたが、私が直面している問題に当てはまる答えはありませんでした。ただし、質問とは異なり、バインドに失敗したというメッセージは表示されません。ブレークポイントがヒットすることはありません。うまくいけば、これはWCFで壁に頭をぶつけて将来誰かに役立つことでしょう。

TL / DR：
SOAPメッセージで、不正なデータを含むレコードがあり、ブレークポイントがヒットしませんでした。

全文：

別のチームのWSDLに基づくWCFサービスがあります。私の定義ではありません。それを制御することはできません...このサービスを通じて他のチームからメッセージを受け取ります。私の場合、メッセージを受信し、データベースのメッセージログテーブルにメッセージを記録できます（これは、サービスメソッドが呼び出される前に発生します）、サービスメソッドが呼び出されているようです（呼び出されていない可能性があります）。 a 202受け入れ。メソッド呼び出し中にデータがデータベースに保存されないことを除いて、通信は機能しています。

サービスが成功の応答を返すので、私はhttpおよびトランスポート関連の問題を除外しました。

そこで、VS2015を起動してサービスをデバッグしました。問題のメッセージは大きいですが、私が期待する範囲内にあります。サービスメソッドの最初の行にブレークポイントを設定して大きなメッセージを送信しましたが、ブレークポイントに到達しませんでした。非常に同じ実行インスタンスで機能していることがわかっている小さなメッセージを試してみましたが、ブレークポイントは正常にヒットしました。したがって、構成内のすべてが正常に見えました。メッセージのサイズに何かあるのではないかと思いました。

私は見つけることができるすべてを試しました-デバッグ構成にあることを確認し、クリーンで再構築し、手動でデバッガーをw3wpプロセス（VSが既にありました）にアタッチしDebugger.Break()、ブレークポイントの代わりに使用し、複数のスタートアッププロジェクトを設定し、テストプロジェクトをアンロードしましたそのため、サービスプロジェクトは.NETの更新、VS2015の再起動、再起動、ローカルIISからIIS Expressへの切り替え、そして保証された最新のWSDLでサービスを再作成することだけでした。重要なことは何もありません。ブレークポイントはヒットしませんでした。

悪いデータのレコードが1つ見つかるまで、大きなメッセージのレコードを1つずつ取り除かなければなりませんでした。私の場合は、2つのDateTimeフィールドに値がない1つのレコードでした。この1つのレコードだけが含まれるメッセージを作成して送信したところ、ブレークポイントにヒットしませんでした。これらの2つのDateTimeフィールドに値を指定し、期待どおりに発生したブレークポイントで同じ（固定）メッセージを送信したとき。

私はすべてのCLR例外を有効にし、.pbdファイルが見つからないこと以外は何も起動しませんでした。WCFは、不良レコードを含むリクエストを喜んで送信しました。契約に基づいてWCFがそれを送信するべきではなかったと言っているのではなく、不良レコードが原因でブレークポイントがヒットしなかっただけです。

— リスマン
ソース
0

デバッグを有効にするには、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"/>
— セレシュキン
ソース
0

他のソリューションを試す前に、ソリューション全体をクリーンアップしてください。以前の回答で述べた他のほとんどすべてを試し、Visual Studioを数回再起動した後、ソリューションをクリーニングするだけでうまくいきました！

— 混沌
ソース
0

ここで提案されたすべてを試しました。最終的に、プロジェクトのプロパティ-> Webの「特定のページ」をローカルの開始URL、ページ、クエリパラメータに設定します。クリーンアップしてデバッグモードで再構築すると、ブレークポイントに到達しました。

— アイリッシュチーフテン
ソース
0

これはかなり後のビルド（VS2017）ですが、C＃プロジェクトでこの問題が発生しました。Visual Studioなどのクリーニング、再構築、再起動を試みた。

Visual Studioを閉じ、ソリューションディレクトリにある隠しフォルダーである.vsフォルダーを削除することで修正されました。.vsフォルダーを削除しても問題は発生しませんが、スタートアッププロジェクトをリセットする必要があります。

— クリスビーモンド
ソース
0

私の場合、を使用しProfilerた後に作成された新しいweb.configファイルがありました。web.configを以前のバージョンに復元すると、この問題は解決しました。これはVS2015 C＃Webアプリケーションでした。

— 熱心な
ソース
0

にConfiguration設定されているWebアプリケーションチェックを発行する場合Debug（デフォルトでは、デバッグ構成では、コードが最適化されず、シンボルテーブルが完全に作成されるように設定されています）。ここに画像の説明を入力してください

— VSB
ソース
-1

私は以前の回答を超える見て、ウィルの@ 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

それでも、これが最善の方法ではないように思います。

— ラルド94
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.