問題タブ [nlog]

NLogを使用していますが、RichTextBoxとFileに同時にログインしたいと思います。そして、xml構成ファイルではなく、プログラムでロガーを構成したいと思います。

次のコードは、最後のターゲット（この場合はファイル）にのみログを記録します。誰か助けてもらえますか？

私はTekpub Starter Siteに基づいた MVC2 アプリを持っているので、依存性注入に Ninject、ログ記録に NLog、およびさまざまな場所にある他のライブラリの束を使用しています。私が知る限り、私の問題を引き起こしているのはこれらです。

私の PC では ASP.NET 開発サーバー (Cassini) を使用してすべてがうまく動作しますが、サーバーにデプロイすると (これは安価な共有ホスティング契約です)、ロガーをインスタンス化する Ninject に関連していると思われる NullReferenceException が発生します。

これが私の Global.asax.cs の関連部分です

nlog.config

NLogLogger クラス:

スタックトレース：

login をコメントアウトするとOnApplicationStarted、別の例外が発生します。ログが発生するべきではないため、なぜロガーをインスタンス化しようとしているのかわからないので、なぜそれが起こっているのかわかりません。

サイトを完全に機能させる唯一の方法は、ロガーを完全に偽装することですが、これにはまったく満足していません。ASP.NET 共有ホスティングで遊ぶのはこれが初めてなので、少し戸惑っています。誰にも役立つ提案はありますか？

人々が依存性注入プラットフォームを使用してログを注入する方法についてもっと知りたいと思っています。以下のリンクと私の例は log4net と Unity を参照していますが、必ずしもこれらのいずれかを使用するわけではありません。依存性注入/IOC については、プロジェクトの残りの部分 (大規模) が落ち着いている標準であるため、おそらく MEF を使用します。

私は依存性注入/ioc に非常に慣れておらず、C# と .NET にもかなり慣れていません (過去 10 年ほど VC6 と VB6 を使用した後、C#/.NET でプロダクション コードをほとんど作成していません)。さまざまなロギング ソリューションについて多くの調査を行ってきたので、それらの機能セットについては十分に理解できていると思います。私は、1 つの依存関係を注入する (または、より「正しく」、1 つの依存関係の抽象化されたバージョンを注入する) 実際のメカニズムに十分に精通していません。

ロギングおよび/または依存性注入に関連する他の投稿を見たことがあります: 依存性注入およびロギング インターフェイス

ロギングのベスト プラクティス

Log4Net ラッパー クラスはどのようになりますか?

再びlog4netとUnity IOC構成について

私の質問は、「ioc ツール yyy を使用してロギング プラットフォーム xxx を挿入するにはどうすればよいですか?」とは特に関係ありません。むしろ、ロギング プラットフォームのラッピング (常に推奨されているわけではありませんが、よくあることです) と構成 (つまり app.config) を人々がどのように処理しているかに興味があります。たとえば、log4net を例として使用すると、(app.config で) 多数のロガーを構成し、次のようなコードを使用する標準的な方法でそれらのロガーを (依存性注入なしで) 取得できます。

別の方法として、ロガーの名前がクラスではなく機能領域である場合は、次のようにすることができます。

したがって、私の「要件」は次のようなものになると思います。

1. 製品のソースをロギング プラットフォームに直接依存しないようにしたいと考えています。

2. 特定の名前付きロガー インスタンス (おそらく、同じ名前付きインスタンスのすべてのリクエスター間で同じインスタンスを共有する) を、何らかの依存性注入 (おそらく MEF) によって直接的または間接的に解決できるようにしたいと考えています。

3. これを難しい要件と呼ぶかどうかはわかりませんが、必要に応じて名前付きロガー (クラス ロガーとは異なる) を取得できるようにしたいと考えています。たとえば、クラス名に基づいてクラスのロガーを作成する場合がありますが、1 つのメソッドには、個別に制御したい特に重い診断が必要です。言い換えれば、1 つのクラスを 2 つの個別のロガー インスタンスに「依存」させたいと思うかもしれません。

番号 1 から始めましょう。ラップするのが良いかどうかについて、主にここでスタックオーバーフローに関する多くの記事を読みました。上記の「ベスト プラクティス」リンクを参照し、jeffrey hantinのコメントにアクセスして、log4net をラップすることがなぜ悪いのかについての 1 つのビューを参照してください。ラップした場合 (そして効果的にラップできた場合) は、直接依存性の注入/除去の目的で厳密にラップしますか? それとも、log4net app.config 情報の一部またはすべてを抽象化しようとしますか?

System.Diagnostics を使用したいとしましょう。おそらく、TraceSource に基づいて、インターフェイス ベースのロガーを実装したいと思います (「共通の」ILogger/ILog インターフェイスを使用することもあるでしょう)。インターフェイスを実装し、たとえば TraceSource を使用して、System.Diagnostics の app.config 情報をそのまま使用しますか?

このようなもの：

そして、次のように使用します。

番号 2 に移ります ... 特定の名前付きロガー インスタンスを解決するにはどうすればよいですか? 選択したロギング プラットフォームの app.config 情報をそのまま利用する必要がありますか (つまり、app.config の命名スキームに基づいてロガーを解決します)? では、log4net の場合、LogManager を「注入」する方がよいでしょうか (これは静的オブジェクトであるため、これは不可能であることに注意してください)。LogManager (これを MyLogManager と呼びます) をラップし、それに ILogManager インターフェイスを与えてから、MyLogManager.ILogManager インターフェイスを解決することができます。私の他のオブジェクトは、ILogManager (実装されているアセンブリからのエクスポート) に依存関係 (MEF 用語でのインポート) を持つことができます。これで、次のようなオブジェクトを持つことができます。

ILogManager が呼び出されるたびに、log4net の LogManager に直接委任されます。または、ラップされた LogManager は、app.config に基づいて取得した ILogger インスタンスを取得し、それらを (?) MEF コンテナーに名前で追加できます。その後、同じ名前のロガーが要求されると、ラップされた LogManager に対してその名前が照会されます。ILogger が存在する場合は、その方法で解決されます。これが MEF で可能である場合、そうするメリットはありますか?

この場合、実際には ILogManager だけが「注入」され、log4net が通常行う方法で ILogger インスタンスを配布できます。このタイプの (本質的にはファクトリの) インジェクションは、名前付きロガー インスタンスのインジェクションと比べてどうですか? これにより、log4net (または他のロギング プラットフォーム) の app.config ファイルをより簡単に活用できます。

次のように、MEF コンテナーから名前付きインスタンスを取得できることを知っています。

しかし、名前付きインスタンスをコンテナーに入れるにはどうすればよいでしょうか? ILogger のさまざまな実装を持つことができる属性ベースのモデルについては知っていますが、それぞれに (MEF 属性を介して) 名前が付けられていますが、それは実際には役に立ちません。ロガー (すべて同じ実装) を名前でリストし、MEF が読み取ることができる app.config (またはその中のセクション) のようなものを作成する方法はありますか? 基礎となるapp.configを介して名前付きロガーを解決し、解決されたロガーをMEFコンテナーに挿入する中央の「マネージャー」(MyLogManagerなど)が存在する可能性がありますか? このようにして、同じ MEF コンテナーにアクセスできる他の誰かが利用できるようになります (ただし、log4net の app.config 情報の使用方法に関する MyLogManager の知識がなくても、

これはすでにかなり長くなりました。首尾一貫していることを願っています。ロギング プラットフォーム (log4net、NLog、または System.Diagnostics 上に構築されたもの (できれば薄い) を検討している可能性が最も高い) をアプリケーションにどのように依存関係に注入したかについて、具体的な情報を自由に共有してください。

「マネージャー」を注入して、ロガーインスタンスを返すようにしましたか?

独自の構成セクションまたは DI プラットフォームの構成セクションに独自の構成情報の一部を追加して、ロガー インスタンスを直接注入することを容易/可能にしましたか (つまり、依存関係を ILogManager ではなく ILogger にします)。

ILogManager インターフェイスまたは名前付きの ILogger インスタンスのセットを含む静的またはグローバル コンテナーを使用する場合はどうでしょうか。そのため、従来の意味で (コンストラクター、プロパティ、またはメンバー データを介して) 注入するのではなく、ログの依存関係はオンデマンドで明示的に解決されます。これは、依存性を注入するための良い方法ですか、それとも悪い方法ですか。

明確な答えがある質問のようには見えないため、これをコミュニティ wiki としてマークします。違うと感じた人は遠慮なく変更してください。

助けてくれてありがとう！

現在、NLogが実際に例外をログに記録していることを証明するために、NLogがCSVファイルを吐き出している。

これは、XMLで出力する必要があることを除いて、期待どおりに機能しています。NLogのドキュメントを調べましたが、Log4JXmlEventLayoutがあることだけがわかりましたが、ドキュメントにはその使用方法が記載されていません。私はNLogを初めて使用しますが、このテーマに関するリソースをあまり見つけることができません。

IISおよびWindowsServer2003でホストされているASP.NETアプリケーションでNLogを使用しています。開発マシンでコードを実行すると、すべて問題ありません。しかし、コードをサーバーにデプロイしたとき。NLogターゲットを初期化すると、セキュリティ例外が発生します。

セキュリティ例外の説明：アプリケーションがセキュリティポリシーで許可されていない操作を実行しようとしました。このアプリケーションに必要な権限を付与するには、システム管理者に連絡するか、構成ファイルでアプリケーションの信頼レベルを変更してください。

ソースエラー：

現在のWebリクエストの実行中に、未処理の例外が生成されました。例外の発生源と場所に関する情報は、以下の例外スタックトレースを使用して識別できます。

スタックトレース：

[SecurityException：要求されたレジストリアクセスは許可されていません。]
System.ThrowHelper.ThrowSecurityException（ExceptionResource resource）+51
Microsoft.Win32.RegistryKey.OpenSubKey（String name、Boolean writable）+7462217
System.Diagnostics.EventLog.CreateEventSource（EventSourceCreationData sourceData）+ 366
NLog.Targets.EventLogTarget.CreateEventSourceIfNeeded（）+637 NLog.Targets.EventLogTarget.InitializeTarget（）+40 NLog.Targets.Target.Initialize（）+264 NLog.Config.LoggingConfiguration.InitializeAll（）+233

アプリケーションに適切な許可を与えるために、いつ私は何をすべきですか？ありがとう！

私は小さなファイル変換ユーティリティを書いています。ファイルは、ディレクトリにドロップされると自動的に変換されます。

ロギングには NLog を使用しています。NLog.confを使用して構成された (生成されたすべてのメッセージを受信する) 中央ログ ファイルに加えて、入力ファイルごとに 1 つの追加のログ ファイルを作成し、同様の名前を持ち、変換プロセス中に書き込まれたすべてのログ メッセージを含めたいと考えています。 .

残念ながら、実行時に新しいファイル ターゲットを適切なルールと共に適切に追加する方法を見つけることができないようです。Logger変換プロセス中に、すべてのオブジェクトが新しいログ ファイルに書き込まれるようにします。

私は何かを試しました

しかし、ログ ファイルは作成されませんでした。

私は何を間違えたのですか？何か案が？

I am trying to convert existing logging library used by a bunch of apps to use NLog. The existing logging code has no indirection, logging calls go straight from the caller to a webservice call. The existing logging code is implemented as a static singleton. I need to do this in such a way that existing applications that use this library do not need configuration or code changes when they pick up the changed logging library. Later I can go update applications on an as needed basis, configuring a new logging target or changing the code to log to NLog directly.

To do this, I was going to make the static logging code go through NLog. Existing logging calls will be routed through NLog, and the existing webservice call will be wrapped in a custom NLog target.

To make this work on legacy apps without changing them, I need to programmatically set the custom target as the default (when none are configured in a config file). I'd like to do this without making config changes on the numerous existing applications, so I need to do this programmatically.

The problem is... its not working. Any thoughts on this approach? Below is the code I tried to add to hook in the existing logger class to create the default target.

I wouldn't mind going to log4net either. Just looking at the APIs I chose NLog initially as the names made more sense to me.

使用<customErrors mode="Off"/>して画面にエラーがあるとログファイルに書き込まれますが、使用する<customErrors mode="RemoteOnly"/>とカスタムエラーページが表示されますが、エラーはキャッチされませんが、ロガー:-/

ロギングに関する他の多くの質問を見てきました。ベストプラクティス。どのロギング プラットフォームが最適か。など。トピックに関する非常に良い議論があるSOのここからのリンクがいくつかあります。

ロギングのベスト プラクティス

log4net と TraceSource

.NET 3.5 プロジェクトに最適なログ ソリューション

.NET 3.5 ロギング

編集を開始:

この長い投稿を入力して、私が理解しようとしている主なことは、WCF のログ記録/トレースとアクティビティ ID の伝達が System.Diagnostics と TraceSources にどれほど緊密に結合されているかということだと思います。log4net や NLog などのサード パーティのログ プラットフォームを使用して、「適切な」WCF ログ/トレースとアクティビティ ID の伝達を取得できますか。これを行う場合、どのようにしますか？

ServiceTraceViewer に関するいくつかの質問については、この投稿の下部を参照してください。

編集を終了します。

私の質問の主題は、これらの投稿のいずれにおいても詳細に議論されていません. ロギングと WCF に関して人々が何をしているかに興味があります。WCF サービスを含むプロジェクトに取り組んでおり、プロジェクトにログインしている場合、WCF 固有のログ機能を使用するために特別な努力をしていますか? 特に、アクティビティ トレース、アクティビティ伝播、エンド ツー エンド トレースなどを取り入れようとしていますか? MSDN のこの記事 で概説されているようなものです。これは、アクティビティの伝達に関するMSDNの別の記事です。

この記事では、System.Diagnostics の TraceSource を使用して、アクティビティのトレース、アクティビティの伝播、およびエンド ツー エンドのトレースを行う方法について説明しています。app.config/web.config ファイルを介してこれらのオプションを「オン」にするように WCF を構成する方法を示します。WCF は内部で TraceSources を使用して、通信の結果をログに記録します。

System.Diagnostics と TraceSources を介してアクティビティの伝播を実現する方法を多かれ少なかれ示すサンプル コード (上記でリンクされた 2 番目の MSDN 記事から) を次に示します。

WCF がアクティビティを伝達したかどうかを、サービス内から確認できる方法を次に示します。

私が見たすべての例から、アクティビティの伝播は System.Service モデルの TraceSource を構成し (通常は app.config を介して)、その propagActivity プロパティを "true" に設定することで達成されます。アクティビティは、Trace.CorrelationManager.ActivityId にアクティビティ ID (guid) を設定することによって実際に伝達されます。log4net または NLog を使用している場合、WCF のログ記録とアクティビティの伝達を効果的に使用できますか?

私のプロジェクトでは、WCF を非常に頻繁に使用します。現在、ロギング ソリューションに落ち着こうとしています。System.Diagnostics および TraceSources で WCF のログ記録とアクティビティの伝達がどのように機能するかについては、かなりよく理解できていると思います。log4net や NLog などのロギング プラットフォームを使用して、同様のことがどのように達成できるかをよりよく理解したいと思います。

彼らは「ネイティブ」サポートを提供していますか？アクティビティの伝播を「手動で」達成できるように、何らかのインフラストラクチャを提供する可能性が少し高いようです。多分このようなもの：

log4net/NLog ログ形式が NDC スタックの一番上をログに記録するように構成されている場合、(アクティビティがスコープ内にある間) クライアントによってログに記録された各メッセージは、アクティビティ ID で「タグ付け」されます。WCF サービスが同様に実装されていると仮定すると、サービス呼び出し中にログに記録されたすべてのメッセージも (おそらく別のファイルに) ログに記録され、同じアクティビティ ID でタグ付けされます。そのため、「サービス」ログ ファイル内のログ メッセージを「クライアント」ログ内の対応するメッセージに関連付けることができます。

したがって、WCF を使用していて、ログを記録している場合は、次の質問があります。

1. アクティビティの伝播を使用していますか?
2. ロギングに TraceSources を使用していますか?
3. 他のログ プラットフォーム (log4net、NLog など) を使用していますか?
4. 別のロギング プラットフォームを使用している場合、アクティビティの伝播はどのように行うのですか?
5. サードパーティのログ (log4net/NLog - ほとんどのログ) とSystem.Diagnostics.TraceSource(WCF サービス境界のログ) を組み合わせて使用​​していますか?

ServiceTraceViewer はどうですか? 使いますか？私が見たほとんどの例は、TraceSources と XmlTraceListener を介して System.Diagnostics によって生成された出力を示しています。log4net、NLog などからの出力を使用できますか? TraceSource ベースのロギングで「最適」に機能しますか? もしそうなら、ServiceTraceViewer で表示するために、WCF サービス境界での TraceSource ベースのロギング (一部のアプリ コンテキストと WCF 通信情報をキャプチャする) を少しだけ持つだけで「十分」でしょうか? 進行中の WCF 学習プロセスの一環として、ServiceTraceViewer を簡単に使用しました。

ここまで読んでくれてありがとう。ログの統合、WCF アクティビティの伝播、および ServiceTraceViewer でログを表示する機能について考えすぎているのかもしれません。ロギング プラットフォームやロギング戦略の選択において重要な考慮事項のように思えますが、これらのロギング プラットフォームや WCF について確実に知るには十分な経験がありません。

Managed Extensibility Framework（MEF）でNLogを使用する最良の方法は何ですか？

MEFアーキテクチャ（インポートおよびエクスポートなど）を使用するプラグインをサポートするアプリケーションがあります。アプリケーションにロギング機能を追加したいと思います。ロギングコンポーネントとして、NLogを使用したいと思います。

あなたは何をお勧めします？1. NLogのラッパーを作成します。つまり、NLogを構成し、他のプラグインがインポートするvoid Log（文字列レベル、文字列メッセージ）などの機能をエクスポートする追加のプラグインを作成します。2。すべてのプラグインにNLogの独自のインスタンスを構成して使用する必要があります。（実際には、すべて同じファイルに書き込みます）。