none
Essential .NET - Logging with .NET Core RRS feed

  • General discussion

  • Why on earth would you need a new logging framework? Because there are already so many available, and the new Microsoft.Extensions.Logging API lets you take advantage of them without having to write a wrapper of your own.

    Read this article in the April issue of MSDN Magazine

    Thursday, April 21, 2016 7:39 PM
    Owner

All replies

  • Reason I always ended up writing my own wrapper around NLog or log4net was not to be able to use different underlying frameworks, but to support gathering of parameters on callback instead of inserting them directly.

    When writing Trace, Debug, or even Info level messages, it is a fair assumption that none of them will be written out in production. However those are methods that typically are given most parameters because, well, because they are useful in development. Gathering all these parameters is sometimes not trivial and can be resource intensive, but since validations of whether to log or not to log are usually not conditionally compiled but checked per some configuration file, parameters are still gathered and passed into .Trace() or whatever other method is used.

    To avoid this I wrap in method with signature such as

    Trace(string message, params Func<object>[] args)

    , where inside Trace it checks if this level of logging is enabled. Then method call looks like this and no extra work is performed unless we really need to log:

    Trace("message to write", () => "first expensive-to-get parameter", () => "second expensive-to-get parameter");
    Unfortunately this does not appear to be supported in new logging framework. Of maybe I am missing something here.



    • Edited by Anatoli M Wednesday, October 5, 2016 11:37 PM
    Wednesday, October 5, 2016 11:27 PM
  • How can I create a LoggerFactory from a 'classic' .NET Framework 4.52 application, which does not use the new project.json?

    Normally I can use the same types, but when using an old csproj-based project, I can get the new ILogger-types (by referencing Microsoft.Extensions.Logging.Abstractions), but how do I create the LoggerFactory itself? All examples google finds target ASP.NET, but I need it in a console app. 

    Friday, October 7, 2016 11:13 AM
  • Wouldn't the call to Trace have to create an array of Funcs, thus incurring an unnecessary allocation in the case when tracing isn't done?
    Saturday, December 10, 2016 12:21 AM
  • Why on earth would you need a new logging framework? Because there are already so many available, and the new Microsoft.Extensions.Logging API lets you take advantage of them without having to write a wrapper of your own.

    Read this article in the April issue of MSDN Magazine

    I think they needed it partly for the internals of .NET itself. In previous versions of .NET they have used a mismatch up special logging classes for completely different parts of the framework. Hopefully they will consolidate all of that to a single solution that we as developers can then tap in to, when we want or need to. 

    The logging solution built in to .NET Core does not support File logging or any advanced features. So it works well for .NET internals but as soon as you need any advanced logging, you will want to switch to NLog or Serilog. 

    I wrote a blog post recently on this topic: ASP.NET Core Logging: What still works and what changed?


    Azure power user for 4 years and .NET developer for 14 years. Founder and CEO of Stackify APM - Advanced application monitoring for Azure

    Tuesday, February 14, 2017 1:09 PM
  • Obligatory XKCD link.
    Thursday, September 28, 2017 12:42 AM
  • The logging framework available under System.Diagnostics namespace had the ability to configure new trace listeners.

    As an example, if you were not happy with the out of box TextWriterTraceListener , then you could very easily add a new NLOG listener through your web.config or app.config file. 

    You also had the System.Diagnostics.TraceSource class that allowed you to log on a per component basis. Through a few lines of configuration in the app.config/web.config you could emit all the information out of your desired component.

    Example of configuring tracing to capture Network traffic.

    https://docs.microsoft.com/en-us/dotnet/framework/network-programming/how-to-configure-network-tracing

    While I like .NET Core, I am still struggling to find merits in the new logging system over the previous one.


    sdg

    Saturday, August 4, 2018 3:07 PM
  • @saurabhd because the new interfaces are a lot more flexible. Just inject ILogger in your services, and add providers to the DI container as needed - including TraceSource, NLOG, and others.

    The same pattern is used with many other technologies. With System.Diagnostics you could configure to add an NLOG listener to the config file, but this is not flexible enough for many scenarios. 

    Thursday, November 1, 2018 9:58 AM