8

.NET Trace および Debug クラスの使用方法について少し混乱しています。

なぜわざわざデバッグの代わりにトレースを使用するのでしょうか?

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

Debug.WriteLine()
Debug.Assert()

また、Release 構成モードでは Debug ステートメントが無視されることは理解していますが、トレース ステートメントが常に適用される場合、パフォーマンスにどのような影響がありますか?

4

4 に答える 4

8

最も単純なレベルでは、異なるコンパイル スイッチがあります。つまり、 etc はコンパイル シンボル (リリース ビルドでは一般的ではありません)Debug.WriteLineがある場合にのみ切り替えられますが、-asは通常、リリース ビルドにも含まれます。DEBUGTrace.WriteLine

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

于 2008-12-31T10:44:14.430 に答える
2

私はリリース環境での作業をログに記録するために Trace (関連する TraceSwitch を使用) を使用する傾向がありました。 ) またはデバッガーをアタッチする必要性。何らかの理由で顧客のマシンでのみ発生する問題に特に便利です。これを使用して、FTP クラスからのログ アウトを正常にダンプし (古い Framework 1.1 の時代にさかのぼります)、2 つの企業間のネットワーク転送の問題を診断するのに役立ちました。

于 2008-12-31T11:05:19.487 に答える
2

プロジェクト プロパティのビルド ページに移動すると、そこにいくつかのチェックボックスがあります。

私にとっての経験則は、実際のデバッグ情報には debug を使用することです。つまり、この時点での変数 x の値は ... などであり、Trace はアプリを介した制御の流れを追跡するために使用します (スパムのようなものです)。

于 2008-12-31T00:24:10.983 に答える
2

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

多くの情報を Trace コンソールに送信するとパフォーマンスが低下するため、確かに送信したくないでしょうが、いくつかの重要な情報は適切な場合があります。

于 2008-12-31T00:27:18.307 に答える