複数のファイルが同じ名前の場合、Visual Studioブレークポイントが間違ったソースファイル（または同時に複数のファイル）で中断する

Question

私が取り組んでいるチームプロジェクトで、ソリューションに同じ名前の別のファイルがある場合、ファイルにブレークポイントを設定すると（たとえば、_IdeasController.cs_）、デバッガーの動作が不安定になります。複数の開発者のワークステーションで問題を再現しました。

例

Web APIの_IdeasController.cs_にブレークポイントを設定します。

_IdeasController.cs_と呼ばれる別のファイルが、別のMVC 4 Webプロジェクトに存在します。以下のスクリーンショットでは、デバッガーは_Api->IdeasController_ソースコードを示していますが、行の強調表示は_Web->IdeasController_のコード構造と一致しています。ブレークポイントが複製され、そのうちの1つがコメントブロックの中央にあります。

ブレークポイントウィンドウには、両方のファイルのブレークポイントが同時に表示されます。

一部のワークステーションでは、デバッガーは（行の強調表示に関係なく）正しい行をステップ実行します。他の人では、関係のない行（コメントや空白を含む）を元気に進めます。これは表示するソースファイルによって異なると思います。

私が試したこと

インターネットをトロールしました。この種の問題は、デバッグファイル（_*.pdb_）、ソースファイル、およびコンパイルされたコードの間に不一致がある場合に発生するようです。考えられる原因はたくさんあります。ファイル名が重複している（デバッガを混乱させる可能性があります）^[5]）、古いプロジェクトビルドファイル、無効なソリューションキャッシュ、または不適切なビルド構成。

これらは私が見つけて試したソリューションです：

ビルド構成を確認しました。
1. プロジェクトがリリースモードでビルドされていないことを確認しました。
2. コードの最適化を有効にしないでください。
3. プロジェクトのデバッグモジュールが正しく読み込まれたことを確認しました。（プロジェクトのデバッグを開始し、Debug> Windows> Modulesをチェックしました。両方のアセンブリが一覧表示され、最適化されておらず、シンボルのステータスが「シンボルが読み込まれています」です。）
デバッグメタデータとVisual Studioキャッシュをリセットします。
1. Visual Studioを閉じ、ソリューションキャッシュファイル（_*.suo_）を削除しました。^[1]
2. 各プロジェクトのビルド出力（binおよびobjフォルダー）を削除しました。（将来の参照用：エクスプローラーでソリューションフォルダーを開き、検索ボックスに「type:folder AND (name:=bin OR name:=obj)」と入力します。
3. アセンブリキャッシュフォルダー（_C:\Documents and Settings\<user>\Local Settings\Application Data\dl3_）を削除しました。^{[2] [3]}

これらのどれも効果がありませんでした。問題を一時的に回避するために（クラスの名前を変更せずに）ファイルの1つを名前変更できますが、それは理想からほど遠いです。

私が今いるところ

最新のGoogle検索の14ページ目。提案をいただければ幸いです。 :)

bdrajer · Answer

より良い代替手段が存在しない場合は、コードにブレークポイントを置くことができます。

System.Diagnostics.Debugger.Break();

後で削除することを忘れないでください...

Miiir · Answer

私がこの投稿を見つけて本当に良かったと思いました。私はVS2012とVB.Netで同じ問題を抱えており、OPについて述べたすべてを試しました。

ファイルの一意の名前は、私が見つけた唯一の100％修正のようです。ほとんどの場合、アプリケーションが読み込まれるまですべてのブレークポイントを無効にしてから、必要なブレークポイントを再度有効にするとうまくいきます。 Lambda関数のブレークポイントでも問題が発生する可能性があります。

Steffen Winkler · Answer

私はまったく同じ問題を抱えていました。私にとってそれを解決したのは、影響を受けるプロジェクト/ソースファイルを含むソリューションに属する.suoファイルを削除することでした。

ローカルシンボルキャッシュも削除しましたが、それとは関係ないと思います。

（私のソリューションには複数のプロジェクトが含まれており、1つのプロジェクトの1つのファイル（DataAdapter.cs）がこれの影響を受けました（VisualStudioがSystem.Data.DataAdapterに属するpdbにブレークポイントを配置しました）.csprojファイルを直接開いて正しくブレークポイントを設定します。）

DSpirit · Answer

Visual Studio 2017（バージョン15.9.7）でこの問題が発生しましたが、ブレークポイントがスキップされ、デバッガーがreturnステートメントなどに「ジャンプ」しました。

しばらくしてから、私は最近.runsettingsファイルをプロジェクトに追加したことに気づきました。その結果、私の場合、CodeCoverageデータコレクターを構成するとこの問題が発生していることがわかりました。このセクションを削除するとすぐに：

<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>

.runsettingsファイルから、それは再び魅力のように働きました。

David Beavon · Answer

今日も同じ問題がありました。デバッグ中にプラットフォームターゲットをx86に設定するのを忘れていたという事実にまで遡ることができました。残念ながら、その他（x64/Any CPU）はデバッグ中に問題が発生する可能性があります。少なくともVS 2008はそれらを好きではありません。これが離れているもう一つの理由だと思います。

一部の憶測...デバッガ（64ビットアプリの実行中）は、特定の場合に、ファイルからブレークポイントを「盗み」ます。私にとっては、同じファイル名を持つ別のアセンブリが最初にロードされたためです。最初にブレークポイントを使用してアセンブリを手動でロードした場合は、64ビットモードでも問題を回避できました。Assembly.Load（ "MyAssemblyWithBreakpoints"）;

これ（私の最初のstackoverflowの貢献）が役に立てば幸いです。

Malarial · Answer

いずれかのファイルの名前を変更しても機能しますが、最も簡単な解決策は、「他の」アセンブリのシンボルの自動読み込みを一時的に無効にすることです。

デバッガーを開始し、誤ったブレークポイントに到達するまで続行します。
デバッガー実際に コールスタックウィンドウを使用してブレークポイントを設定する場所を見つける：
1. 黄色の矢印のある行を右クリックし、モジュール名の表示を有効にします。（行には赤いブレークポイントシンボルも含まれている必要があります。）
2. アセンブリ名がその行に表示されます。
モジュールウィンドウでそのアセンブリを見つけます（デバッグ>ウィンドウ>モジュール）。
アセンブリを右クリックしてAlways Load Automaticallyを無効にします。
デバッガーを停止します。
再度デバッグを開始します。

これにより、Visual Studioデバッガーがブレークポイントを間違ったアセンブリにマッピングするのを防ぐことができます。次に、他の[おそらく]正しいアセンブリからシンボルを最初にロードし、ブレークポイントを正しいアセンブリにマッピングします。

なぜこれが起こるのですか？

これは、2つの異なるアセンブリの2つの異なるシンボルファイル（PDBファイル）が両方とも同じ名前のソースファイルを参照している場合に発生するようです。ソースファイルは完全に異なりますが、Visual Studioデバッガーは混乱するようです。

たとえば、IdeasController.csという名前の2つの異なるファイルがあるとします。 1つ目はアセンブリApi.dllにコンパイルされ、2つ目はアセンブリWeb.dllにコンパイルされます。

デバッガーがシンボルをロードするとき、Api.pdbまたはWeb.pdbを最初にロードします。最初にApi.pdbをロードするとします。次に、Web\IdeasController.csにブレークポイントを設定した場合でも、IdeasController.csでApi.pdbに一致するものが見つかります。次に、コードをWeb\IdeasController.csからApi.dllにマッピングします。もちろん、これは正しくマッピングされないので、デバッグ中にあらゆる種類の奇妙な問題が表示されます。

Jan Lecko · Answer

ファイルをバックアップして削除し、プロジェクトに追加し直すだけで問題は解決しました。私は前述のリストを通過する前にそれをやっただけです:)

Patrick · Answer

この問題はVisual Studio 2015で発生していました。

DLLを含むサブフォルダがありました。Version1として保存したいのです。そのDLLへの参照を削除してから、既存の参照でプルされた別のプロジェクトスタジオへの参照を追加した後でも、間違ったソースファイルに移動しました。サブフォルダにあるDLL=を削除すると、Studioは正しいソースを取得しました。

[MSDNに役立つリンクが見つかりました。これは、スタジオで以前に関連付けられていたソースファイルをこのリンクで消去する方法を示しています] [1]。

概要：

ソリューションエクスプローラーで、ソリューション名（例：Solution ‘TestApplication'）を右クリックし、[プロパティ]を選択します。これにより、[ソリューションプロパティページ]ダイアログが表示されます
Common Propertiesで、Debug Source Filesを選択します。
[ソースコードファイルのこれらのパスを検索（Visual Studio .NET 2003）/ソースコードを含むディレクトリ（Visual Studio 2005）]ボックスで、必要に応じてディレクトリを追加、削除、または並べ替えます
OKボタンをクリックします

Altaf Virani · Answer

私は同じ問題を抱えていました。私の場合、両方のプロジェクトのポート番号は同じでした。ファイルのブレークポイントがヒットしないプロジェクトのポート番号を変更することで解決できました。

私の推測では、IIS Expressは2番目のプロジェクトのpdbファイルをキャッシュしていました。両方のファイルの名前が同じで、プロジェクトのポート番号が同じだったためです。

Diogo · Answer

すべてのプロジェクトを（ビルドではなく）クリーンアップして再ビルドすることもできます。

Stefan Michev · Answer

私は非常に似た問題を抱えていました。私の場合、問題はプロジェクトの1つにある別のターゲット.netフレームワークであり、VS2017が別のプロジェクトのソースファイル（同じ名前）を誤ってロードしました。

ObjectHandle handle = Activator.CreateInstance

すべてのプロジェクトで同じになるようにプロジェクトのターゲットフレームワークを変更すると、修正されました。

Ramaraj K · Answer

ブレークポイントが誤ってヒットしているプロジェクトのすべての.pdbファイルを削除します。これで問題は解決します。

Simone · Answer

同じメモリアドレスと同じ関連ファイルの2つの子ブレークポイントが（VS 2008で）偶然起こりました。これらのブレークポイントは、プロセスの実行中の特定の時間に生成されました。

プロジェクトフォルダーに.dllファイルが重複していることに気づきましたそして、重複する.dllを削除し、デバッグフォルダーに名前ごとに.dllを1つだけ残して解決しました構造。（私の場合の例として、私は/bin/Example.dllと/bin/Plug-in/Example.dllの両方をデバッグフォルダー構造の下に置いていました）。

batintherain · Answer

私（VS2017）で機能したのは無効 Tools --> Options... --> Debugging --> Generalのこのオプションです： "ソースファイルが元のバージョンと完全に一致する必要があります"、これはデフォルトで有効になっていますが、オンにしてもらいました。

しかし、それだけでは十分ではなく、ソリューション内のすべてのプロジェクトのobjおよびbinフォルダーを手動で削除する必要もありました。