デフォルトのフォーマットで、標準のエンタープライズライブラリテキストフォーマッタを持っています。ログファイルは適切に作成されますが、空のままです。最後のフォーマットオプションを削除すると、拡張プロパティ（以下を参照）を使用して機能し始めます。元に戻すと、ログは空のままで、エラーを検索する場所がわかりません。
template="Tim...
Extended Properties: {dictionary({key} - {value}{newline})}"
（はい、正確に省略されたテンプレートを使用して実行し、エラーをトリガーできます）。パーツを削除すると、{dictionary({key} - {value}{newline})}ログが開始されます。この問題はテストサーバーでのみ発生します。ローカルの開発マシンでは期待どおりに機能し、拡張プロパティが出力されます。
別のロギングエラーの宛先を設定しようとしましたが、うまくいきませんでした。そこには何も記録されません。
@TimBはおそらく正しいと思います。
これに関連 する未解決の問題があります。 「元の例外が報告されない理由は、例外を報告するときに別のTextFormatterが使用され、キャッチされて飲み込まれる別の例外がスローされるためです（ただし、ロギング失敗イベントが発生します）。」
回避策は、ExtendedPropertiesにnullを設定しないことです。または、おそらくカスタムフォーマッタ。
ExtendedPropertiesディクショナリにnullを含めることはできません。Enterprise Libraryはこのディクショナリにnullオブジェクトを想定していないため、これによりロギングが失敗します。これが問題であるかどうかを診断するには、「ログのエラーと警告」カテゴリを構成してどこかにログを記録します。そうすると、ログの記録時に発生しているエラーを確認できるはずです。
私が遭遇した別の問題は、拡張プロパティの欠落を引き起こしLogger.Write、オブジェクトを例外として扱わないため、拡張プロパティをログに記録しないというオーバーロードです。
1つのオプションは、exception.Dataをディクショナリにキャストし、それを3番目のpropertiesパラメーターとして渡します。
2番目のオプションは、代わりExceptionPolicy.HandleExceptionに例外をログに記録するために使用されます（例外ポリシーが例外を適切なログカテゴリに送信すると仮定します）。