C++ DLLを参照するとASP.NETがデバッグされない - ブレークポイントがヒットしない

Question

私のASP.NET Webページには、C++ .NET DLLによって提供されるデータが必要です。このDLLを読み込んで最初に関数を呼び出す限り、すべて正常に動作するように見えましたが、現在はプロジェクトが.csファイルのDLLを参照すると実際にデバッグしない状態になっているようです。

DLLを参照するコードをすべてコメントアウトして、プロジェクトから参照を削除しました。うまくいきました。私は、DLLへの参照を追加して、うまくいきました。 DLLのネームスペース（この場合はMDnlnkCmdReaderを使用）のusingステートメントのみをコメント解除し、DLLを参照する実際のコードは残さず、今ではデバッグ時にブレークポイントにヒットしません。その行を再びコメントアウトし、ブレークポイントが再びヒットします。

ウェブページが正しくロードされているように見えるが、ブレークポイントに到達していない状態になると、ソースコードに戻ってブレークポイントを表示すると、警告フラグ付きのアウトラインとして表示されます私はそれらをマウスオーバーすると、 "ブレークポイントは現在ヒットしません。ソースコードは元のバージョンとは異なります"

私もそのエラーメッセージを見て、通常の解決策を試しました。私が/ binフォルダ全体を壊すと、global.asaxに関するWebサーバのエラーメッセージが出ます。これらは、任意のCPUモード（通常はx64でビルド）でビルドされるまで続きます。その時点で、DLL（x64で構築された）に関するメッセージを「読み込めません」というメッセージが表示されます。それへの参照を削除すると、ページは再び動作します。 x64モードに戻ってリファレンスを戻してください。私はどこから始めたのでしょうか？リブートするとどちらも助けにならないようです。

ここで何が起こっているのか、どのようにそれを脱出するのですか？あなたは、デバッグと「パス」欄を見ている間

Answer 1

さて、私はこれを今考え出したと思います。私が扱ってきたことは、実際には2つの異なる問題です。

最初の問題は、ASP.NET開発サーバーが唯一のプロジェクトの/binフォルダからそのDLLをつかむことをいとわないように見えるということです。 任意のCPUに設定されている場合はプロジェクトがビルドされますが、x86またはx64に設定されている場合、デフォルトはbin/x86/Debugまたはbin/x64/Debugになります。あなたがx86またはデフォルトのビルドの場所でx64に設定されている場合、開発サーバは、まだ/binフォルダのルートからDLLをつかむしようとします。

Any CPUという名前のプロジェクトを作成したことがない場合、または最後にインストールした後に/binフォルダを削除した場合は、DLLが見つからず、開発サーバーに「Couldタイプ「WebDownlink.Global」を読み込まないでください。「（WebDownlinkは、プロジェクトの名前空間である）あなたのGlobal.asaxファイルについて。これは、それはそれはあなたのDLLを見つけることができないので、それが唯一の/binフォルダのルートに見ているためであるあなたの名前空間を、ロードできないことを意味します。

プロジェクトをAny CPUとしてビルドし、x86またはx64にビルドした場合、新しいビルドは適切なサブディレクトリにありますが、開発サーバーは最後のAny CPUビルドのファイルを引き続き取得します。ビルドしたばかりのファイルを使用しているので、最後のAny CPUビルド以降に何か変更した場合は、別のソースコードエラーが発生し、デバッグが正しく機能しません。デバッグは動作しますが、開発サーバーはまだAny CPUバージョンを実行しています。これは、脆弱性が問題となる場所で何かをしようとしている場合には、あなたを混乱させる可能性があります。

この正しい解決策は、x86モードを/bin/x86/Debugフォルダではなく/binフォルダのルートに構築するように設定されているようです。または、最初に管理されていないDLLを参照しないでください。

これは、ASP.NET開発サーバーが32ビットモードでのみ実行され、64ビットシステム上のIISアプリケーションプールは64ビットモードでのみ実行されるという2番目の問題に繋がりますこれらのいずれかを変更する方法については、私に教えてください）。 Any CPUとしてビルドすることができないアンマネージDLLにコードをリンクする必要がある場合、これを考慮する必要があります。だから私は上記のx86しか参照していません - あなたのx64がどこにビルドするかは、開発サーバーがそれを実行しないため変更する必要はありません。

幸いなことに、自分のコードが参照するDLLのソースがあり、何も参照していないため、開発サーバーと開発サーバーの両方で32ビットモードと64ビットモードを簡単に構築できます完全なIISです。再構築できない32ビットDLLを参照している場合は、32ビットマシンに展開するか、IISアプリケーションプールを32ビットで実行する方法を見つけなければならないでしょう。 t。 DLLが64ビットで再構築できない場合は、完全なIIS上で関連するコードのデバッグをすべて行うだけで済みます。

私の解決策はDLLを32ビットで構築し、リファレンスをリセットしてから、出力パスを/binに設定して32ビットモードでビルドすることです。私が展開したいときは、DLLを64ビットで再構築し、リファレンスをリセットし、64ビットでプロジェクトをビルドしてから、IISにデプロイします。

Answer 2

は、「モジュール」ウィンドウを開き - あなたは組み立てあなたが一致したソースコードを知っているアセンブリを一致させるためにパスが与えられたのでしょうか？

ASP.NETは、通常、 "Temporary ASP.NET Files"フォルダにアセンブリのコピーを置きます。したがって、これもクリアする必要があります。

ソースファイルがでない限り、元のバージョンと完全に一致するようにデバッグすることができるように、ソースファイルをオフにすることもできます。しかし、根本的な問題を修正する方が良いでしょう（アセンブリはソースと一致しません）。