0

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

DLL を参照するすべてのコードをコメントアウトし、プロジェクトから参照を削除したところ、問題なく動作しました。DLL への参照を追加したところ、問題なく動作しました。DLL の名前空間 (この場合は MDnlnkCmdReader; を使用) の using ステートメントのみをコメント解除し、DLL を参照する実際のコードを残していません。その行をもう一度コメントアウトすると、ブレークポイントが再びヒットします。

Web ページが正しく読み込まれているように見えるがブレークポイントにヒットしないこの状態になると、ソース コードに戻ってブレークポイントを表示すると、注意フラグ付きのアウトラインとして表示され、マウスオーバーすると、次に、「ブレークポイントは現在ヒットしません。ソースコードは元のバージョンとは異なります」と表示されます

私もそのエラーメッセージを調べて、通常の解決策を試しました。/bin フォルダー全体を削除すると、global.asax に関する Web サーバー エラー メッセージが表示されるようになります。これらは、任意の CPU モード (通常は x64 でビルド) でビルドするまで持続します。その時点で、DLL (x64 でビルド) に関する「ロードできません」というメッセージが表示されます。それへの参照を削除すると、ページは再び機能します。x64 モードに切り替えて参照を追加し直すと、開始した場所に戻ります。再起動しても効果がないようです。

ここで何が起こっているのか、それから抜け出す方法はありますか?

4

2 に答える 2

2

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

/bin最初の問題は、ASP.NET 開発サーバーが、プロジェクトのフォルダーからのみ DLL を取得しようとしているように見えることです。Any CPUに設定されている場合、プロジェクトはそこにビルドされますが、x86またはに設定されている場合x64、デフォルトではbin/x86/Debugまたはにビルドされbin/x64/Debugます。デフォルトのビルド場所に設定されている場合x86でも、開発サーバーはフォルダーx64のルートから DLL を取得しようとします。/bin

プロジェクトを としてビルドしたことがない場合Any CPU、または/bin前回ビルドしてからフォルダーを消去した場合、DLL がまったく見つからず、開発サーバーは「タイプ 'WebDownlink.グローバル'。" Global.asaxファイルについて（WebDownlinkはプロジェクトの名前空間です）。これは、名前空間を読み込めないことを意味します。これは、/binフォルダーのルートのみを検索しているため、DLL を見つけることができないためです。

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

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

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

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

したがって、私の解決策は、DLL を 32 ビットでビルドし、参照をリセットしてから、出力パスを に設定して 32 ビット モードでビルドすること/binです。配置する場合は、DLL を 64 ビットで再ビルドし、参照をリセットして、プロジェクトを 64 ビットでビルドし、IIS に配置します。

于 2012-05-11T15:42:16.003 に答える
0

デバッグ中に「モジュール」ウィンドウを開き、「パス」列を見てください。アセンブリに指定されたパスは、ソース コードと一致することがわかっているアセンブリと一致しますか?

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

「ソース ファイルが元のバージョンと正確に一致する必要がある」のチェックを外すこともできることに注意してください。これにより、ソース コードがそれほど遠くない限り、デバッグが可能になります。ただし、代わりに根本的な問題 (アセンブリがソースと一致しない) を修正することをお勧めします。

于 2012-05-10T15:46:20.210 に答える