0

When someone writes a Microsoft.Extensions.Logging.ILogger.LogCritical() call, there must be some serious things happened. I hope it will (log critical and) break while run in debugger. I've try the answer of How to override an existing extension method, it requires special namespace using. But I hope that everyone can use LogCritical() naturally, no need to double check whether it's calling original LogCritical() or my trapped one.

The only way I can think of is replace the backing logging library with mine, and it redirect calls to logging library with my breaking logic. But this implement restrict to specified library. If I want to change library in the future, I need to implement another one. And implement all the boring interfaces it needs, just for a few LogCritical() related breaking logic.

So, I wish to trap the general ILogger.LogCritical() call, not the underlying concrete one. Is this possible?

ChrisTorng
  • 742
  • 7
  • 18
  • The .NET Core logging framework allows you to register many loggers, I suggest you create a new custom logger that does what you want and use it in-conjunction with your existing NLog logger. – Matthew Sep 09 '19 at 18:13

1 Answers1

1

Not sure what you are looking for. But maybe something like this:

   var logFactory = NLog.Web.NLogBuilder.ConfigureNLog("nlog.config");
   #if DEBUG
   var debugBreakTarget = new NLog.Targets.MethodCallTarget("DebugBreak", (logEvent,parms) => System.Diagnostics.Debugger.Break());
   var debugBreakRule = new NLog.Config.LoggingRule("*", NLog.Level.Fatal, debugBreakTarget);
   logFactory.Configuration.LoggingRules.Insert(0, debugBreakRule);
   logFactory.ReconfigExistingLoggers();
   #endif
   var logger = logFactory.GetCurrentClassLogger();

Showing NLog-specific-solution since you have added NLog-tag to your question.

See also: https://github.com/NLog/NLog/wiki/MethodCall-target

Rolf Kristensen
  • 17,785
  • 1
  • 51
  • 70
  • Thanks for your answer. I wish a general trap on ILogger, not NLog specific one. But your `MethodCallTarget` is a new thing for me to learn. But after I try it (in NLog.config), if I use `async="true"`, the call stack doesn't include the `LogCritical()` one. (Although in log file I can found the last Fatal log, but break in debugger is much better. I can check every values related in debugger, not the log message only.) Only `async="false"` works. But this hurt performance a lot and can't be accepted by my current project. – ChrisTorng Sep 10 '19 at 02:42
  • @ChrisTorng When using NLog.config then you can have multiple sections. And you can just put the MethodCall-target in its own -section with async="false" – Rolf Kristensen Sep 10 '19 at 05:33
  • I should not try NLog.config one. It makes production environment check for every log request, makes all logs slower. I should use your `#if DEBUG` way, that only affects debug environment. Although your way only works in NLog library, not my original question that wish a general `ILogger.LogCritical` trap. But it does solve my current project's problem. So I'm marking your answer as accepted. – ChrisTorng Sep 16 '19 at 03:38