Mono.Cecil に関する 最近の トピックの影響を受けて、プロセス自動化のタスクが生まれたことは驚くことではありません。
製品が内部の企業価値だけでなく、社会的に有用であるために、「内部」ロガーのサポートに限定するのではなく、サードパーティのlog4netおよびnlogをサポートすることも決定されました（残念ながら、内部のニーズについては、スムーズにlog4netに切り替えます）。
タスクを具体化するには、ロガーの呼び出しを関数の先頭に追加し、エントリの事実だけでなく、関数が呼び出されたパラメーターも記録する必要があります。
エントリーは遅れ、言葉から行為へと移る時が来ました。
実装は、コンパイル後の段階で実行され、各関数の開始時にLogger.Debug（ "Entering"）呼び出しを注入するmsbuild-taskです。 むしろ、それぞれではなく、 [Log]属性のみでマークされています。 または、すべてのクラスで、この属性でマークされた関数。 [ログ]属性がAssemblyInfoに追加されている場合は、モジュールの各機能の開始時に、または最初に。 関数のログを記録したくない場合は、 [NoLog]属性でそれらをマークできます。
このmsbuildタスクを実行するには、その呼び出しを.csproj \ .vbprojに追加する必要があります。 たとえば、次のように：
<Import Project="c:\path\to\Logging.NLog.targets" />
まあ、または少し変更、log4netを好む場合。
さらに、もちろん、これがログに記録されるロガーインスタンスを作成する必要があります。 現在のLoggingMagicは、クラスの静的フィールドを介してロガーインスタンスにアクセスできることを意味します。
// - Logger - . , .targets- public class Logger { public static NLog.Logger Log = NLog.LogManager.GetLogger("NlogConsoleApp"); }
以上です。 結果のログストリームのフィルタリングは、ロギングライブラリに完全に依存しています。 LoggingMagicは非常に簡単に展開できます。属性の名前とロガーを持つクラスは、msbuildタスクのパラメーターで変更されます。
重大な欠点は、クラスごとのロガー技術（たとえば、nlogによって伝播される）のサポートがないことです。ロギングは、静的フィールドまたは静的関数のいずれかで可能です。 コメントでは、どのロギング方法を使用するかを知ることは興味深いでしょう:)クラスごとのロギングはおそらく永続的なコミュニティ要件で追加されます:)
その結果、 Log4Postsharpとの簡略化された類似性が得られましたが、独自のコンポーネントに縛られることなく、サードパーティとリンクしてインストール中にこれを提供する必要もありません（loggingmagicライブラリはBuildserverを超えています）。
このすべての不名誉のソースコードはcodeplexに配置されています
PS実際の入力ロギングの必要性-不必要性に関する議論にすべてが結び付かないことを願っています。これは、ほとんどの場合、主題分野によって決定されるためです。 特定のケースでは、これはクライアントのインストールで問題が検出されたときに詳細情報を収集する唯一の方法である場合があります。