サーバー上で実行される DLL があり、多くの理由でデバッグできません。例外をログに記録します。
時々"Object reference not set to an instance of an object"、例外の原因となったオブジェクトがどこにあるかを知るのに長い時間がかかる約20個のパラメーターを持つメソッド呼び出しがあります。
"Object reference not set to an instance of an object"例外の原因となったオブジェクトの名前の場合、例外をログに記録する方法はありますか?
null だった正確な引数をログに記録したい場合(デバッグは問題外のように聞こえます)、各パラメーターを null について個別にテストArgumentNullExceptionし、渡されたパラメーターの名前で null の場合はそのパラメーターに対して をスローする必要があります。例外のコンストラクタへの文字列。
これは、20 個のパラメーターを受け入れるメソッドが難しいメンテナンスの問題につながる可能性がある (多くの理由の 1 つです)。メソッドの責任が多すぎて、必要以上のことをしようとしている可能性があることを示しています。コードを作成しているときに、このメソッドを小さな断片に分割することを検討することをお勧めします。
例外が発生する行がわかっている場合は、Redgate .NET Reflector Freeを使用してアセンブリを逆アセンブルし、詳細情報を取得できます!
それ以外の場合: いいえ、argumentException (パラメーターの名前が例外に含まれる場合) がある場合を除いて、例外の原因となったパラメーター名を取得する機会はありません。
これを引き起こしているオブジェクトを特定する最も簡単な方法は、実行中のコードにデバッガーをアタッチすることです。おそらく、デバッグ モードでビルドされたコードを実行する別のサーバーを実行する必要があります。Visual Studio で Debug -> Exceptions... メニュー項目に移動すると、2 列の例外タイプのダイアログが表示されます。共通言語ランタイム例外のスローされた列を確認します。次に、例外がスローされている操作を試してください。これは、どのオブジェクトが問題を引き起こしているかを示す最も簡単な方法です。
このエラーが表示されることによって引き起こされる副作用があるかどうかを確認し、そこから逆トレースすることもできます。
エラー メッセージだけでなく、エラーのスタック トレース全体を出力することもできます。これにより、必要な詳細が得られる場合があります。