OK、私が持っているもの：

Visual Studio 2010 RC、W7 x64は、Silverlightアプリケーションの新しいプロジェクトタイプを開始しました。ASP.NET WebアプリケーションプロジェクトでSilverlightアプリケーションをホストします。Silverlightバージョン3.0。LinqToSQLクラス、WCFサービス、Winform Testerアプリケーション（ソリューションのプロジェクト）、およびいくつかのクラス（ソリューションのプロジェクトとして）を追加しました。

昨日、突然、「ブレークポイントは現在ヒットしません。このドキュメントにはシンボルが読み込まれていません。IDEに表示されるメッセージですが、これはWebアプリケーションにのみ影響します。SilverlightとWinformアプリをデバッグできます。

メッセージを取り除くために私が試した/やったこと：

• Visual Studio設定をリセットする
• すべての\ Temporary ASP.NET Filesフォルダ内のすべてのファイルを削除しました（32ビット/ 64ビットごと、およびFramework 2.0および4.0ごとに1つあります）
• Visual Studio統合Webサーバーを使用してデバッグを試みました-通常はIISを使用していますが、ソリューションのプロジェクト出力では、すべてのプロジェクトフォルダー内のすべてのobjフォルダーとbinフォルダーを削除しました
• 新しいソリューションを作成し、すべてのプロジェクトをこの新しいソリューションに追加しました
• ソリューションsuoファイルを削除しました
• VSインストールの問題かどうかをテストする新しいASP.NET Webアプリケーションを作成しました=>この新しいプロジェクト/ソリューションをデバッグできます
• マシンを数回再起動しました
• vs.netインストールを修復しました
• IISResetを行いました
• IISからWebアプリを削除
• IISで新しいWebアプリを作成するために、Webアプリのプロジェクトプロパティの下にある[仮想ディレクトリの作成]ボタンを使用しました
• すべてのプロジェクトのフレームワークバージョンを3.5から4.0に変更
• 2台目のマシンでソリューションを開いた=>同じ動作
• バグ/同様の問題のためにMicrosoft Connectをクロールした
• 7時間を費やします。

つまり、これは私の人生で2回目です。前回はTemporary ASP.NET Files Folderを削除して解決しましたが、今回はあなたの助けが必要です。

ソリューションを右クリック->プロパティ

Common Properties-> Startup Projectを確認します

複数のスタートアッププロジェクトを選択する

デバッグする必要があるプロジェクトで[開始]アクションを選択します。

私は同じ問題を抱えていましたが、グーグルした後、これに対する2つの典型的な解決策を見つけました：

1. Silverlightデバッガーが.Webプロジェクトでアクティブ化されていることを確認します。プロジェクトのプロパティを開き、[Web]タブでSilverlightデバッガーを選択します。

2. Visual Studioを再起動して、binおよびobjフォルダーをすべて削除します。

しかし、これらのどれも私にとってはうまくいきませんでした。次に、誰かがスレッドのはるか下で、代わりにブラウザとしてIEを使用することを試みたと述べました。これにより、デバッグとブレークポイントが再び機能するようになりました。

編集：

その後、IE9が間違ったプロセスにアタッチされるため、IE9が機能しないことに苦労しました。毎回手動で正しいIEプロセスにアタッチする代わりに、きちんとしたトリックを見つけました。

• .Webプロジェクト（.htmlまたは.aspx）で生成されたページの1つを右クリックします。
• [次で参照...]をクリックします
• IEを既定のブラウザーとして設定（Visual Studioのブラウザーの選択にのみ影響します）

これで、.Webプロジェクトの実行時にVisual StudioがIEを起動し、正しいプロセスにアタッチします。それでうまくいくはずです。

この特定のエラーが発生するたびに、Visual Studioがアセンブリを読み込んでいるフォルダーが、Webアプリケーションを実行しているフォルダーとは異なることが判明しました。

つまり、アプリケーションサーバーは、

C:\dev\MyApplication\bin 

しかし、Visual Studioは

C:\dev\MyOtherApplication\bin (or something along those lines, anyway).

注-さまざまな理由により、ほとんどの人が使用する不安定なスタンドアロンギズモではなく、アプリケーションホストとしてIISを使用してデバッグを行っています。これは私の答えの有用性に影響を与える可能性があります！

更新：

IISの場合、アプリケーションサーバーディレクトリ（C:\dev\MyApplication上記）は、Webアプリケーション用に構成された物理ディレクトリです。これは、アプリの基本設定を変更することで制御できます。

Visual Studioの場合、デバッグディレクトリ（C:\dev\MyOtherApplication上記）はsvcファイルが見つかったディレクトリであり、通常はcsprojプロジェクトファイルと同じディレクトリです。

私にとっての問題は、デバッグ構成で[プロパティ]-> [ビルド]-> [コードの最適化]チェックボックスがオンになっていることでした。オフにして再構築し、デバッグは通常どおり機能しました。

直面した理由は、PDB（「PDBはProgram Databaseの略で、プログラムに関するデバッグ情報を格納するための（Microsoftが開発した）独自のファイル形式です）が最新ではないためです。これは、いくつかの理由が原因である可能性があります：

1- Bevanが言ったように、別のアプリケーションをデバッグしている可能性があります！

2-同じアプリケーションの別のバージョンをデバッグしています。たとえば、以前にビルドしたアプリケーションに現在のバージョンのコードをアタッチして、それを（再）ビルドせずにデバッグしました。

ソリューションをクリーニングまたは再構築すると、このような問題が解決します。

問題があなたのものではないことを確認するには、VS 2008で同じアプリケーションをデバッグしてみてください（VS 2010のバグの可能性があります-まだベータ版です！）。

同じ問題があり、プロジェクトをデバッグしていて、プロジェクトを右クリックして「新しいデバッグインスタンス」を選択する必要がありました。私はこれを1回だけ実行する必要があり、その後は通常どおり機能しました。

このエラーは時々発生します。私にとっては、関係するアセンブリのプロジェクト設定にいつでも遡ることができます。どのアセンブリにシンボルが読み込まれているのかを知るために、コードがブレークポイントを順守できないか、ブレークポイントを設定するまで「待機」する必要はありません。

デバッグモードでプロジェクトを実行すると、以下のようにシンボルが読み込まれたアセンブリが出力ウィンドウにリストされます（新しいタブで画像を開く必要がある場合があります）：T

したがって、この場合、BASD.Core.Data.dllにはシンボルがロードされていません。そのため、このアセンブリのプロジェクト設定を、シンボルをロードできた別のアセンブリのプロジェクト設定と比較して、シンボルが読み込まれる理由と読み込まれない理由を突き止めることができます。

「私にとって」しかし、これが「毎回」発生するのは、デバッグ情報が作成されていないためです。（C＃）プロジェクトで[プロジェクトのプロパティ]> [ビルド]> [詳細設定]を開きます。

したがって、上記のBasd.Core.Data.dll、つまりシンボルがない場合、高度なビルド設定は次のとおりです。

一方、Bassd.Core.Configuration.dll、つまり、ブレークポイントを設定してヒットできるアセンブリの設定は次のとおりです。

したがって、最初のプロジェクトではなく、後者のプロジェクトでデバッグ情報を出力しているため、Basd.Core.Configuration.dllのブレークポイントに到達できます

また、特定の.dllのプロジェクトのbinフォルダーに.pdbファイルを置くだけでは十分ではないことにも注意してください。ステップスルーしようとしている。

また、ビルド構成を変更すると、ビルド情報の設定とシンボルの取得元が変わる可能性があることにも注意してください。

（この場合、私はリリースモードですが、方法はまだ適用されています）

Goto Project Properties-> Build-> Advanced ...

[出力]セクションの[デバッグ情報]ドロップダウンで[完全]を選択します

プログラムをRELEASEモードではなくDEBUGモードで実行していることを確認してください。

デバッグ - > プロセスにアタッチ - >
選択デバッグにこれらのコードの種類を：オプション- >
選択マネージドV3.5、V3.0、V2.0またはマネージドV4.5を、V4.0

Silverlightアプリケーションの展開に従って、この問題を解決しました。（この回答は他の回答と重複していますが、詳しく説明するつもりです。）

この問題は、ビルド/起動時にSilverlightアプリケーションがWebアプリケーションに適切にデプロイされていない可能性が高いです。これは参照の問題です-理解するのは簡単ですが、初めて遭遇したときは明らかではありません。

ただ、他のプロジェクトの参照と同様に、参照先プロジェクトの出力をにコピーする必要が参照しているデバッグするために、プロジェクトのbinフォルダ。クラスライブラリの場合、これは右クリックして[参照の追加...]を選択すると発生します。Silverlightの場合、プロジェクトプロパティを使用して参照を追加する必要があります。

• プロジェクトを右クリックして、[プロパティ]を選択します
• 左側の[Silverlightアプリケーション]タブを選択します
• [追加...]ボタンを押して、ダイアログボックスからSilverlightプロジェクトを選択します

これにより、ホスティングWebアプリからSilverlightアプリケーションへの参照が追加xapされ、ビルドまたはデプロイ時にファイルがWebアプリに確実にコピーされます。つまり、現在のSilverlightアプリとそのデバッグファイルは、デバッグ対象のアプリケーション内にあり、コードをステップ実行できるようになります。

Webプロジェクトをデバッグする場合は、web.configファイルでdebug = "true"属性が設定されていることを確認してください。

<system.web>
    <compilation debug="true"   .../>

私はWindows 7 でも同じ問題を抱えており、DLLのクリーニング、モジュールのリストの調査、「Just My Code」の無効化など、すべてを試しました。

「管理者として」Visual Studioを実行した後、問題は解決しました。正直なところ。マイクロソフトが「管理者として」実行されていないことを警告することができなかったのはなぜですか？それは私にいくつかの時間の節約になります。

私にとっての問題は、プロジェクトの設定の[ビルド]タブで[コードの最適化]を有効にしていたことでした。

同じ問題があった

何らかの理由で、DLLの1つがGACに登録されていたため、コードとは常に異なるバージョンでした。

GACから削除すると、問題は解決しました

Visual Studio 2010ではなくVisual Studio 2008を使用していて、このエラーが発生しているユーザー向け。上記の答えはこの状況では私を助けなかったので、私の経験を共有します。

デバッグにASP.NET開発サーバーを使用するのではなく、w3wp.exeプロセスにアタッチしてVisual Studio 2008でIIS Webアプリケーションをデバッグする場合（デバッグから開始）、これが問題になる可能性があります。

Visual Studioは、古くなっているIISプロセスのdllからシンボルファイル（デバッグ中に使用されるファイル）をまだ参照している可能性があります。そして、そのシンボルファイルは.NETソースコードの再コンパイルによって再作成されましたが、IISプロセスはまだ古いシンボルファイルを参照しています。

修正するには：

Visual Studioでのデバッグを停止し、Webアプリケーションを再起動して、プロセスに再アタッチするだけです。その後、ブレークポイントは黄色（このエラーが表示された場合）から再び赤に変わります。

========================

試してみるべきこと（今日、新しい状況が見つかりました）：

以下のリンクの各箇条書きを一度に1つずつ実行しますが、試行するたびに以下の手順を繰り返します。

http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.）Visual Studioでデバッグを停止（赤い四角のアイコンを押します）
2.）ソリューションをクリーン
3.）ソリューションをビルド
4.）[ここにバレットの手順を挿入]
5 .）[ツール] > [プロセスにアタッチ]（またはデバッグを開始）
6.）接続しているプログラムを起動し、コードがヒットするように実行します

6説明した：

nunit.exeにアタッチする場合は、NUnitを開いてテストを実行し、ブレークポイントにヒットするようにします

w3wp.exe（IISサイト）に接続する場合は、ブラウザーでサイトを開き、ブレークポイントに到達するページに移動します

編集：

今日、スタートアッププロジェクトとして設定されていないプロジェクトでデバッグしようとすると、これが表示されることに気付きました。w3wp.exeプロセスにアタッチすると、起動プロジェクトとして設定されているプロジェクトでのデバッグと見なされます。解決するには、Webアプリケーションプロジェクトを右クリックして、[Set As Start Up Project]を選択します。次に、プロセスに再接続してみてください。

シナリオは次のとおりです。特定のプロジェクトがスタートアッププロジェクトです（たとえば、Mainメソッドがあります）。そのプロジェクトは、ソリューション内の他のプロジェクトを参照しています。他のプロジェクトのブレークポイントはヒットしていません。

クイックソリューション：ソリューションをビルドするときは、ビルド出力パス（通常はbin \ Debug）で起動プロジェクトを探します。参照しているプロジェクトのDLLおよびPDBファイルを確認します。最終変更日が、ソリューションを最後に作成した日付であることを確認してください。そうでない場合は、各プロジェクトのビルド出力パスからスタートアッププロジェクトのビルド出力パスにコピーします。例えば：

プロジェクトAにはメインがあります。プロジェクトBを参照しています。ブレークポイントはプロジェクトBでヒットしていません。DLLとPDBファイルをプロジェクトBのビルド出力パスからプロジェクトAのビルド出力パスにコピーします。次に、ソリューションを実行します。ブレークポイントがヒットします。

ここで、プロジェクトAがプロジェクトBのDLLとPDBファイルをコピーしていない理由を理解する必要があります。ここでの回答はほとんどのシナリオをカバーしています。触れられていない1つのシナリオは、プロジェクトとソリューションがTFSに適切にバインドされていることを確認することです。いくつかのプロジェクトをバインドしましたが、いくつかは正しくバインドしていませんでした。それが私に問題を引き起こしました。それを修正すると、問題はなくなり、DLLとPDBファイルをコピーする必要がなくなりました。

私の場合の同じ問題の解決策は、次の手順の組み合わせでした。

1. ソリューション->プロパティ複数のスタートアッププロジェクトを選択し、デバッグする必要のあるプロジェクトで[開始]アクションを選択します。
2. サービスをサービス参照から削除し、ソリューションをクリーンアップしました。
3. サービスプロジェクトを再構築する
4. サービスリファレンスに追加し直しました
5. ソリューションをクリーンアップして再構築します。

Web.configでこの問題を修正するには、追加する必要がありました debug="true"

  <system.web>
    <compilation targetFramework="4.0" debug="true">

この解決策を見つけるのに役立ったのは、デバッグ中にモジュールウィンドウを調べていて、読み込まれたASP.NET DLLで、デバッグ情報を使用してバイナリがビルドされていないことがわかりました。

私は同じ問題を抱えていましたが、VS2013でWebアプリを使用しています。私にとっての答えは、ソリューションのビルド構成を更新することでした：-

1. ソリューションを右クリックして、プロパティを選択します
2. デバッグ構成を選択します
3. トリベットの「構成プロパティ」で「構成」を選択します
4. デバッグする各プロジェクトの[ビルド]ボックスをオンにします

これを実行すると、すべてのブレークポイントが機能し始めました。

わかりました-ここに行きます：

（「silverlightアプリ」の場合：まず、サーバープロジェクトの「プロパティ」の「web」でsilverlightがチェックされていることを確認してください。それでも解決しない場合は、下に試してください）

初めて実行：最初に実行：devenv.exe / ResetSettingsおよび1：トップメニューでデバッグタグをクリックします2：オプションと設定をクリックします3：[デバッグ]で[一般]の下にある[.netフレームワークソースのステップ実行を有効にする]を見つけます4：ボックスをチェックします。5：そして今、すべてのシンボルがダウンロードされ、再構成されます:)

上記の後に再度発生する場合は、シンボルがあるフォルダをクリアします。

1：トップメニューでデバッグタグをクリックします2：オプションと設定をクリックします3：[デバッグ]で[シンボル]の下にある[空のシンボルキャッシュ]ボタンを見つけてクリックします

ブラウザーからWebアプリケーションのURLを開き、VS.Net IDEで[ツール]-> [AttachtoProcess]を使用します。

次に、aspnet_wp.exeにアタッチします。

デバッガが動作し始めます

レジストリから.dllのすべてのインスタンス、およびローカルドライブから.dllのすべてのインスタンスを手動でアンインストールする必要がありました。アプリをアンインストール/再インストールして、ブレークポイントに達しました！これをしている半日を無駄にしました:(。

私.pdbはobj\debugフォルダ内のファイルの名前を変更してみて、クリーンなソリューションを実行して再構築しました。
新しい.pdbファイルが作成され、ブレークポイントに正しく到達することができました。

私は同じ問題を抱えていました-Visual Studioでデバッグを機能させるために多くの時間を失いました。

最終的にNugetになりました-Newtonsoft.Jsonの3つのバージョンがありました（7つのC＃プロジェクトで）。ソリューションはコンパイルされましたが、デバッグできませんでした。

Nugetのパッケージマネージャーコンソールで次のコマンドを実行して問題を修正しました。

PM> Update-Package Newtonsoft.Json

私のWPFアプリでは、アプリケーションフォルダーを削除し、ソース管理から再度 "Get Latest"を実行して再構築しました。すべてのブレークポイントが正常に機能します。

Silverlightアプリケーションプロジェクトをスタートアッププロジェクトとして設定してみます。プロジェクトを右クリックし、[スタートアッププロジェクトとして設定]をクリックします。次に、F5キーを押して、ブレークポイントをキャッチできるかどうかを確認します...

Silverlightアプリケーションに変更を加えるたびに、ブラウザーの閲覧/一時データを削除してみてください

役に立つかもしれない別の逸話-

私のプロジェクトの1つがリリース出力フォルダーからのファイル参照を使用していたときに、この問題が発生しました。ビルド結果がGoodsフォルダーに配置されると、これらのリリースdllがデバッグdllを上書きしていました。

解決策はcsprojファイルで確認することでした、私の参照のHintPathは

<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>

ではなく

<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>

クライアントで、アプリケーションソリューションごとに、ほとんどの共有アセンブリを「References」フォルダーにコピーし、ソリューション内の「Solution items」と「Project」の両方としてソリューションに追加したときに、この問題が発生しました。

理由はまだわかりませんが、アセンブリの参照設定で正しい完全パスが指定されていても、デバッグ可能なものとデバッグできないものがあります。

この予測できない行動は私を怒らせました:)

これを解決するには、ソースコードを含むプロジェクトが存在する「References」フォルダーからすべてのアセンブリを削除し、共有アセンブリのバージョン情報を非常に適切に追跡します。

私の問題がばかげたこと以外は同様の問題がありました-組み込みのWebサーバーの2つのインスタンスが2つの異なるポートで実行されており、プロジェクト->プロパティ-> web->「開始URL」が固定ポートを指していますが、 Webアプリは実際にはそのポートで実行されていませんでした。そのため、私のブラウザーは1539を参照する「開始URL」にリダイレクトされていましたが、コード/デバッグインスタンスはポート50803で実行されていました。

組み込みのWebサーバーを固定ポートで実行するように変更し、そのポートを使用するように「開始URL」を調整しました。プロジェクト->プロパティ-> web->「サーバー」セクション->「Use Visual Studio Development Server」->特定のポート