プロジェクトはすべて、Silverlightでログインする必要があるという事実から、まったく平凡に始まりました。
「大人」の.NETでは、常にJarek KowalskiのNLogを使用しました。 そして、なぜlog4netではない、あなたの多くは尋ねます。
もちろん、すべてが非常に主観的ですが、まあまあです。
それは味と色、フェルトペンとプラスチシンですが、NLogは単に優れています。 立証されないようにするために、私はいくつかのキラー基準を与えます...
- 便利な設定。 log4netの後-新鮮な空気の息吹のよう。
- ライブラリは、.NETプラットフォーム用のプロフェッショナルな.NETプラットフォームによって作成されました。これは、ソースとアーキテクチャで確認できます。 同じlog4netは、ソースによって判断すると、.NET用に単純にコンパイルされたJavaコードであり、構文エラーが修正されています(結局、C#はまったくJavaではありません)。
- プロジェクトは積極的に開発中です。 先日、Mono、Silverlight、CFを含むすべての.NETスタックをサポートする最初のベータ版NLog 2.0がリリースされました。 同じlog4netは、チェックインによって判断すると、シャギーな2003年に開発が停止しました。
この比較を終了し、ソリューションに直接進みます。
- NLog 2.0 beta 1をダウンロードしてインストールします。
- SilverlightプロジェクトにNLog.dllへのリンクを追加します。 VS.NET 2010用の生産性向上ツールがあります。アセンブリリンクを追加するための非常に新しいダイアログがあり、SilverlightバージョンのNLogへの正しいリンクを自動的に見つけます。
- プロジェクトに追加新しいアイテム-> NLog | コンソールNLog構成。 プロジェクトにNLog.configという新しいファイルを取得します。 これは、ロギングの静的構成です。 このファイルのビルドアクションがコンテンツモードであることを確認してください。 私はそれをリソースにドロップし、開始時に設定を読み取って初期化しようとしました。 NLogがすべてを処理してくれることがわかりました。 主なことは、構成ファイルがプロジェクトのルートにあり、ビルドアクション->コンテンツであることです。 私が言ったように、構成は静的です。 NLog.configはxap-archiveに保存されており、不必要なジェスチャーなしで変更されません。 デスクトップ.NETアプリケーションの場合のように、NLog.configを変更するときにロギング構成が自動的に更新されることには疑問の余地はありません。
- 単純なSilverlightアプリケーションからファイルにログを記録することはできません。 もう1つは、完全に信頼できる場合ですが、このモードは最初は異常です。 したがって、ネットワーク経由でリモートマシンにログインします。 クライアントは、 log4netのユーザーの狭いサークルで広く知られているLog2Consoleクライアントになります。
だから、私たちは書く:
static readonly Logger _log = LogManager.GetCurrentClassLogger();
そして:
_log.Debug(" {0} NLog", DateTime.Now);
ここで私は少し失望することを期待していました。 SilverlightはUDPソケットをサポートしていないことがわかりました。 したがって、NLogをリッスンすることができたLog2ConsoleからのUDPレシーバーは、Silverlightでは無意味です。 SilverlightはTCPソケットをサポートしていますが、Log2ConsoleでTCP-Receiverが見つかりませんでした。 さて、Log2Consoleの精神で、TCPをサポートするものを探しましょう。
ちなみに、ネイティブのNLog-ovsky NLogViewerはバグが多いため、アルファ版にもなりませんでした...
したがって、
地下室を自分で書くことが残っています。
腕を上げてベルトを締め、ひもを締め、食物と食料を用意し、私はマリアナのプログラミングの不況に突入しました...
1時間で、Log2ConsoleのTCP-Receiverの準備が整いました。 これは、NLog.configでのTCP-Receiverの構成です。
<target name="network" xsi:type="NLogViewer" address="tcp4://deepblue:4505" />
しかし、ここでも、少し失望が待っていました。 Silverlightが特別な招待なしにポートにデータを注ぐことはできないことがわかりました。 まず第一に、利用できるポートは3ダース(4502-4532)のみであり、それらは単純ではありませんが、許可が必要です。 つまり、ポート943のターゲットマシンは、誰がナットを取得するかを示す特別なClientAccessPolicy.xmlファイルをホストする必要があります。
ブログで誰かからこのポリシーサーバーのソースコードを見つけてコンパイルして実行した後、Log2ConsoleでSilverlightアプリケーションから送信されたテストメッセージを見つけました。
これで、気配りのある読者はリラックスする時間だと言うでしょう。 しかし、いいえ、翌日、このポリシーサーバーを起動することを常に忘れていたため、Log2Consoleのエントリを削除し、怒りました。
コリの前/終了/十分/ Genug! -別のReceiver、つまりSilverlightClientAccessPolicy-ReceiverをLog2Consoleに追加しました。 Log2Consoleは実行中のレシーバーの構成を保存し、再起動時に復元します。これは非常に便利です。 今、私はポリシーサーバーを起動することを忘れないで、私は怒っていません:)
ここでは、すでにリラックスし始めることが可能です...
しかし、そこにありました。 Log2Consoleの作成者に連絡し、問題を説明して解決策を提案しました。 Ctrl + Enterを振ると、Log2ConsoleがWPFを使用していることに気づきました...私は強く反対していませんでした...しかし、Log2ConsoleはWinFormsのアプリケーションです。WPFには犬のような5番目のホイールが必要です。
要するに、その夜、Win32CodePackからの外科的介入により、Windows 7タスクバーの機能を切り取りました...
LINQも途中でスローされました(2つの最小/最大メソッドが使用されました)...
そのため、Log2Consoleは.NET 2.0のサポートを開始し、私は、好むと好まざるとにかかわらず、オープンソースの貢献者になりました...
Silverlightおよび.NET Framework 2.0をサポート
する Log2Consoleの更新バージョンは、
ここからダウンロードできます 。 NLogプロジェクトサイトは
こちらです。
これで物語は終わりです。聞いた人は誰でもよくやった!