TraceSourceクラスのメソッドについて

Question

お世話になります。mkmarimoと申します。

 

TraceSourceクラスのTraceData()とTraceEvent()について質問させてください。

 

【質問1】

　TraceData()、TraceEvent()がともに第二引数に持つ"イベントの数値識別子"なるものの使い道はなんでしょうか。

　オーバーロードされたメソッドすべてがこの引数を持ち、必ず指定が必要みたいですが、使い道がわかりません。

　どんな情報を渡してやればよいのでしょうか。

 

【質問2】

　TraceData()とTraceEvent()の動作はどこが違うのでしょうか。

　TraceData()はstring型の引数を渡すことができず、Object型を渡す専用のようですが、使い方がイマイチわかりません。

　TraceData()のヘルプを読むと以下のような記述があります。

 

コード ブロック

TraceEvent メソッド同様、TraceData メソッドは自動化ツール用ですが、例外インスタンスなどの追加オブジェクトをトレースにアタッチする場合にも使用されます。

 

 

　例外オブジェクトなどの追加オブジェクトをトレースにアタッチするとはどういう動作になりますでしょうか。

　また、これを行うと得られるメリットはなんでしょうか。

 

　これらのことより、

　　・TraceEvent()→文字列によるログ出力専用

　　・TraceData()→TraceEvent()にできること＋α

　といったイメージですが間違っていますでしょうか。

 

 

無知な質問で申し訳ありませんが、よろしくお願いいたします。

Answer 1

この件どこかで見たような気がすると思いましたら

過去スレッド「クラスライブラリ(DLL)の構成ファイルについて」
http://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=2122531&SiteID=7
の質問者の方ですね。
この件、三輪の牛様のご回答とmkmarimo様ご自身のご返信でご納得されているように見えたのですが…

mkmarimo さんからの引用

【質問1】 　TraceData()、TraceEvent()がともに第二引数に持つ"イベントの数値識別子"なるものの使い道はなんでしょうか。 　オーバーロードされたメソッドすべてがこの引数を持ち、必ず指定が必要みたいですが、使い道がわかりません。 　どんな情報を渡してやればよいのでしょうか。

アプリケーション全体の作成者自身が決める仕様の話だと思います。

 

例外等に一意のコードを結び付けて管理するのはよくあることだと思います。

コード1はXXXXXXX例外

コード2はYYYYYY例外

…　…　…

この事前に取り決めた「コード」を渡せばよいと思います。

 

mkmarimo さんからの引用

【質問2】 　TraceData()とTraceEvent()の動作はどこが違うのでしょうか。 　TraceData()はstring型の引数を渡すことができず、Object型を渡す専用のようですが、使い方がイマイチわかりません。 　TraceData()のヘルプを読むと以下のような記述があります。   コード ブロック TraceEvent メソッド同様、TraceData メソッドは自動化ツール用ですが、例外インスタンスなどの追加オブジェクトをトレースにアタッチする場合にも使用されます。     　例外オブジェクトなどの追加オブジェクトをトレースにアタッチするとはどういう動作になりますでしょうか。 　また、これを行うと得られるメリットはなんでしょうか。   　これらのことより、 　　・TraceEvent()→文字列によるログ出力専用 　　・TraceData()→TraceEvent()にできること＋α 　といったイメージですが間違っていますでしょうか。

そのイメージで合っていると思いますが、TraceDataもTraceEventに比べてできること自体は大差ないと思います。

TraceDataに例外オブジェクトや状態を詳細記録したいオブジェクトなどを添付できるのは、

たぶん、カスタムでトレースリスナ（TraceListener クラスの派生）を作成した場合に、

TraceListener.TraceData メソッド

http://msdn2.microsoft.com/ja-jp/library/6w7c542z(VS.80).aspx

側でオブジェクトを展開して詳細に記録できるようにするためだと思います。

TraceEventでも同じ内容を出力できますが、オブジェクトから文字列に展開するのがアプリ側になってしまうということだと思います。

アプリケーションの本来の処理と、トレース記録のためのオブジェクトの展開ロジックを分けることができるので、うまくカスタムトレースリスナを作るなら、TraceDataを使用する方がいいかもしれませんね。

Answer 2

IIJIMASさん

 

お世話になります。mkmarimoです。

 

ご回答ありがとうございます。

 

IIJIMAS さんからの引用

この件どこかで見たような気がすると思いましたら 過去スレッド「クラスライブラリ(DLL)の構成ファイルについて」 http://forums.microsoft.com/MSDN-JA/ShowPost.aspx?PostID=2122531&SiteID=7 の質問者の方ですね。 この件、三輪の牛様のご回答とmkmarimo様ご自身のご返信でご納得されているように見えたのですが…

 

そうです。同じような質問を何度も投稿してしまい、申し訳ありません。

一旦、三輪の牛さんの回答で納得しましたが、そのあと、引き続きTraceSourceクラスを利用していたら、

理解度が深まるにつれ、またよくわからなくなってしまったので、改めて質問させていただきました。

なので、ご回答がいただけて助かりました。

 

さて、いただいたご回答の内容についてですが、

 

IIJIMAS さんからの引用

アプリケーション全体の作成者自身が決める仕様の話だと思います。   例外等に一意のコードを結び付けて管理するのはよくあることだと思います。 コード1はXXXXXXX例外 コード2はYYYYYY例外 …　…　… この事前に取り決めた「コード」を渡せばよいと思います。

 

なるほど。例外に一意のコードを結びつけて管理するというやり方があるのですね。

経験が浅いので勉強になります。

いただいた回答を参考にこの"イベントの数値識別子"の使い方について再度考え直してみます。

 

IIJIMAS さんからの引用

そのイメージで合っていると思いますが、TraceDataもTraceEventに比べてできること自体は大差ないと思います。 TraceDataに例外オブジェクトや状態を詳細記録したいオブジェクトなどを添付できるのは、 たぶん、カスタムでトレースリスナ（TraceListener クラスの派生）を作成した場合に、 TraceListener.TraceData メソッド http://msdn2.microsoft.com/ja-jp/library/6w7c542z(VS.80).aspx 側でオブジェクトを展開して詳細に記録できるようにするためだと思います。 TraceEventでも同じ内容を出力できますが、オブジェクトから文字列に展開するのがアプリ側になってしまうということだと思います。 アプリケーションの本来の処理と、トレース記録のためのオブジェクトの展開ロジックを分けることができるので、うまくカスタムトレースリスナを作るなら、TraceDataを使用する方がいいかもしれませんね。

 

なるほど。カスタムトレースリスナを作りたい場合は確かに有効そうですね。

その発想は思いつきませんでした。

MSはそこまで見越したクラス設計を行っているのですね。

 

三輪の牛さんの回答に加え、IIJIMASさんのご回答でTraceSourceクラスについてダメ押しで納得性が高まりました。

ありがとうございました。