トレースおよびデバッグステートメント

StackOverflow https://stackoverflow.com/questions/401910

  •  03-07-2019
  •  | 
  •  

質問

.NETトレースおよびデバッグクラスの使用方法について少し混乱しています。

デバッグの代わりにトレースを使用するのはなぜですか？

Trace.TraceError()
Trace.TraceInformation()
Trace.Assert()

Debug.WriteLine()
Debug.Assert()

また、リリース設定モードではデバッグ文が無視されることを理解していますが、トレース文が常に適用される場合、これはパフォーマンスにどのように影響しますか？

役に立ちましたか？

解決

最も単純なレベルでは、異なるコンパイルスイッチがあります。つまり、 DEBUG コンパイルシンボルがある場合にのみ Debug.WriteLine などが切り替わります（リリースビルドでは一般的ではありません） Trace.WriteLine は通常、リリースビルドにも含まれます。

Trace ルートにはカスタマイズ可能なトレースリスナーがあり、構成を介して組み込むことができます。通常、 Debug はリスナーとしてデバッガーに送られます。もちろん、はるかに高い柔軟性を提供するサードパーティのトレースシステムがあります。

他のヒント

コンパイラスイッチを使用して、独立してオンとオフを切り替えることができます。プロジェクトプロパティのビルドページに移動すると、チェックボックスがいくつかあります。

経験則として、実際のデバッグ情報にはdebugを使用します。つまり、この時点での変数xの値は...などです。また、アプリを介した制御フローを追跡するためのTrace（スパムなど）です。

おっしゃるように、トレースコールはリリースモードの場合にのみ実行されます。リリースモードでコンパイルすると、エンドアプリケーションで必要になる可能性のあるパフォーマンス上の利点がいくつかあります。また、リリースモードをオンにする他の理由がある場合があります。ただし、トレースコンソールに情報を記録したい場合があります。この情報は、 SysInternalのDbgView 。これらは通常、必ずしもログ出力に送信したくないメッセージ、またはユーザーがロギングをオフにしている場合でも常にデバッグ目的で使用できるようにするメッセージです。

パフォーマンスのペナルティを課すため、トレースコンソールに大量の情報を送信したくないのは確かですが、いくつかの重要な情報が適切な場合があります。

リリース環境でのログ記録作業にTrace（関連付けられたTraceSwitchを使用）を使用する傾向があります-app.configをすばやく調整すると、再コンパイルを必要とせずにさまざまなレベルのログを記録できます（問題が発生する可能性があります）とにかく消える）またはデバッガをアタッチする必要があります。何らかの理由で顧客のマシンでのみ発生する問題に特に便利です-これを使用して、FTPクラスのログアウト（古いFramework 1.1日に戻った）を正常にダンプし、2社間のネットワーク転送の問題の診断に役立てました

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top