log4net と NLog に関する多くの情報は、こちらの StackOverflow で、より一般的にグーグルで検索することで見つけることができます。
System.Diagnostics に関する多くの情報も見つけることができます。System.Diagnostics について注意すべきことの 1 つは、Debug.Write/WriteLine および Trace.Write/WriteLine の使用に関する StackOverflow の参照が多数あることです。間違いなく「より良い」方法は、TraceSources を使用することです。TraceSource は、log4net および NLog のロガーに似ています。TraceSource を使用すると、ロギング メッセージの粒度を高めることができるため、ロギングのオンとオフを簡単に切り替えることができます (レベル別だけでなく、クラスまたはカテゴリ別)。TraceSources には、log4net や NLog と比較して欠点があります。コードで作成する各 TraceSource は、app.config で明示的に構成する必要があります (実際にログに記録する場合)。
log4net と NLog には階層的な概念があり、要求した正確なロガーが明示的に構成されていない場合、その「祖先」がチェックされて「祖先」が構成されているかどうかが確認され、構成されている場合は、要求されたロガーがそれらの設定を「継承」します。祖先は、「.」で区切られたロガー名の一部です。(つまり、 という名前のロガーをリクエストすると"ABC.DEF.GHI"、先祖は になり"ABC.DEF"、"ABC"）。また、明示的に構成されておらず、先祖が構成されていない場合、すべてのロガー要求がフォールバックする app.config に「ルート」ロガー構成を含めることもできます (必須?)。したがって、特定のレベルでログを記録するように「ルート」ロガーのみを構成すると、コード内のすべてのロガーがそのレベルでログを記録します。または、「ルート」ロガーを「オフ」に構成してから、1 つ以上のロガーを明示的に (または先祖を構成することによって) オンにすることもできます。このように、NO ロガーは構成されているものを除いてログに記録しません。
ここを見ると、log4net や NLog と非常によく似た継承機能を提供する System.Diagnostics TraceSources の興味深いラッパーが見つかります。
説明する：
log4net と NLog のロガーの一般的な使用パターンは、次のようなロガーを取得することです。
//log4net
static ILog logger = LogManager.GetLogger(
System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
//NLog
static Logger logger = LogManager.GetCurrentClassLogger();
どちらの場合も、ロガーの名前は完全修飾型名になります。
app.config ファイルで、必要に応じて「ルート」ロガーのみを構成すると、両方のロガーがルート ロガーの設定 (レベル、アペンダー/ターゲットなど) を継承します。または、名前空間のロガーを構成することもできます。その名前空間でタイプが定義されているすべてのロガーは、それらのロガー設定を継承します。
log4net と NLog については十分説明しましたが、おそらくそれらがどのように機能するかは既にご存じでしょう。
上記のリンクは、同様の構成を可能にする TraceSource ベースのラッパーを示しています。したがって、必要に応じて、クラスで次のようなことを行うことができます。
static TraceSource ts = new TraceSource(
System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
上でリンクされたラッパーを使用すると、TraceSource を上位レベル (レベルではなくクラス/名前空間の階層単位) で構成し、それらの設定を下位レベルのロガーに継承できます。
したがって、完全修飾型名が ABC.DEF.GHI のようなものである場合、ABC または ABC.DEF (名前空間レベル) の TraceSource を構成すると、クラス "GHI" が設定を継承します。これにより、必要な構成の量を大幅に減らすことができます。
クラスのタイプまたはタイプ名を使用してロガーを取得することに (これらのロギング プラットフォームのいずれでも) 制限されないことに注意してください。おそらく機能領域 (「Communication」、「Communication.Send」、「Communication.Receive」など) に基づいて、独自のロガー命名スキームを定義できます。繰り返しますが、ロガー/TraceSource を最高の粒度で (またはそうではなく) 要求し、意味のある粒度のレベルで構成できます。
したがって、次のようにコードでロガーをリクエストできます。
ILog logger = LogManager.GetLogger("Communication.Receive");
ILog logger = LogManager.GetLogger("Communication.Send");
Logger logger = LogManager.GetLogger("Communication.Receive");
Logger logger = LogManager.GetLogger("Communication.Send");
TraceSource ts = new TraceSource("Communication.Receive");
TraceSource ts = new TraceSource("Communication.Send");
app.config ファイルで「通信」のみを構成すると、すべてのロガーがそれらの設定を継承します (「通信」の子孫であるため)。「Communication.Receive」のみを構成すると、「Communication.Receive」ロガーのみがログに記録されます。「Communication.Send」ロガーは無効になります。「Communication」と「Commuincation.Receive」の両方を構成すると、「Communication.Receive」ロガーは「Communication.Receive」設定でログを記録し、「Communication.Sender」ロガーは「Communication」設定でログを記録します。log4net と NLog では、それ以上の継承が存在する可能性がありますが、それについて詳しく知るには十分ではありません。
System.Diagnostics を使用するときに見落としがちなことの 1 つは、ログ出力形式を非常に簡単にフォーマットできる柔軟性です。TraceSource ベースのロギング用に非常に優れた構成可能なフォーマットを提供するサード パーティ ライブラリがあります。ここで見つけることができます。
Common.Logging一部を使用しました。主にプロトタイピングですが、次のプロジェクトで使用する可能性があります。それはかなりうまく機能し、プラグインする独自のロギング抽象化を作成するのは比較的簡単です (上記でリンクしたものと同様の TraceSource 抽象化を作成したい場合など)。現在 Common.Logging に欠けている 2 つの重要な要素 (彼らの Web サイトには「次の」リリースが予定されていると書かれていますが) は、ログ コンテキスト (log4net、NLog NDC/MDC/GDC オブジェクト、System.Diagnostics.CorrelationManger.LogicalOperationStack など) です。 ) と Silverlight の互換性。Common.Logging を使用している間でも、コード内で log4net または NLog コンテキスト オブジェクトとやり取りすることはできますが、それはその目的を無効にしますね。
助かったかどうかわからない！
log4net、NLog、および TraceSource について、いくつかの主なポイントを次に示します。
log4net - 非常に人気があり、おそらくいくつかの更新が必要です - 少なくとも .NET 4.0 で構築されており、最後のリリースは数年前で、非常に柔軟です。
NLog - 多くの点で log4net と非常によく似ています。新しいバージョンになりました (NLog 2.0 のベータ版が出たばかりです)。
TraceSource - サード パーティの依存関係はなく、log4net や NLog ほど強力ではない (重要な欠陥 - ロガー階層、出力フォーマット - どちらも上記のリンクから簡単に対処できます)、Microsoft は多くのコンポーネントを装備しています。 System.Diagnostics を使用すると、Microsoft のログ出力と自分のログ出力を交互に取得できます。(一般に、他のロギング システムで System.Diagnostics をキャプチャするのは簡単なので、大きな問題にはならないかもしれません)。
私は log4net も NLog もあまり使用していませんが、主に出てきたばかりの新しいバージョン (ベータ版) のために、2 つのうち NLog に傾倒します。特にロガー階層を実装し、上記にリンクされている Ukadc.Diagnostics ライブラリを使用する場合は、TraceSource も合理的であると思います。
または、Common.Logging を使用すると、準備が整うまで、基盤となるログ プラットフォームの決定を回避または遅らせることができます。とにかく、私にとって Common.Logging の非常に便利な側面の 1 つは、アプリケーション コードを一切変更することなく、製品を開発しているときにロギング プラットフォームを「テスト駆動」できることです。コードにロギングを追加する特定のロギング プラットフォームを決定するまで待つ必要はありません。Common.Logging API を使用して今すぐ追加します。配信が近づくと、ロギング プラットフォームの選択が絞り込まれているはずです。そのプラットフォームを配布すれば (ロギング プラットフォームを再配布する場合)、完了です。必要に応じて、後で変更することもできます。