ASP.NET Core 1.0 built-in Logging Framework

  • 2016.07.22: Updated to ASP.NET Core RTM

Logging is a critical feature in any piece of software. Logging is really so boring but it is so important to have logging in place when starting a new solution, it will save you so much time and be a significant help in the investigation of the essence of problems. With ASP.NET Core 1.0, we don't need another third party library to log our application. It is out of the box! Since ASP.NET Core is modular so all we need is to install the following extension:

It has been summarized in the following official documents of the fundamentals : .
Around here, because I want to firmly understand before actually performing the development, I'm going try to touch one way. Because before you can use the examples Logging, it is necessary to add a service to the DI, you keep calling the AddLogging method. This ILoggerFactory and ILogger will be handled via the DI.

using Microsoft.AspNetCore.Builder;  
using Microsoft.AspNetCore.Hosting;  
using Microsoft.Extensions.DependencyInjection;  
using Microsoft.Extensions.Logging;  
using Microsoft.Extensions.Configuration;

namespace EmptyWebApplication  
{
    public class Startup
    {
        public Startup(IHostingEnvironment env)
        {
            var builder = new ConfigurationBuilder()
                .SetBasePath(env.ContentRootPath)
                .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
                .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

            builder.AddEnvironmentVariables();
            Configuration = builder.Build();
        }

        public IConfigurationRoot Configuration { get; }

        public void ConfigureServices(IServiceCollection services)
        {

        }

        public void Configure(IApplicationBuilder app, 
                              IHostingEnvironment env,
                              ILoggerFactory loggerFactory)
        {
            var log = Configuration.GetSection("Logging");
            loggerFactory.AddConsole(log);
            loggerFactory.AddDebug();            
        }
    }
}

We have carried out the additional provider for Configure : ILoggerFactory.

When made from templates, and providers to be output to the console, it has been added to the provider to be output to the debug window in Visual Studio. By implementing the ILoggerProvider, you can implement your own provider.

Providers that are provided by default are as follows.

  • Console
  • Debug
  • TraceSource
  • Windows EventLog

If you use Visual Studio and Azure Web Apps you might be good in about Console and Debug, but you might be better that had been taken into consideration also to implement the TraceSource and proprietary provider.

Logging of settings in the appsettings.json is something like the following, setting of LogLevel have been made to be output.

{  
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "Information",
      "Microsoft": "Information"
    }
  }
}

Making settings in the Startup class, rest if to receive the ILogger in the class such as a controller, it will be easier to make the logging.

If this does not specify the type parameters when, you must be careful because it is not resolved in the DI.

Because the type parameter is no problem if you specify the class to use the logger, I think the most simple controller will make you feel like following.

public class HomeController : Controller  
{
    public HomeController(ILogger logger)
    {
        _logger = logger;
    }

    private ILogger _logger;

    public IActionResult Index()
    {
        _logger.LogInformation("loulou");
        _logger.LogError("loulou");

        return View();
    }
}

Because for the ILogger it is prepared the extension method, so that it outputs a log with the appropriate LogLevel.

When you receive a ILoggerFactory instead ILogger in the constructor at this time, you can create any number of any ILogger.

public class HomeController : Controller  
{
    private ILogger _logger;
    public HomeController(ILoggerFactory loggerFactory)
    {
        _logger = loggerFactory.CreateLogger();
    }

    public IActionResult Index()
    {
        _logger.LogInformation("loulou");
        _logger.LogError("loulou");

        return View();
    }
}

When I do this, it is output log in the debug window in Visual Studio. Since the default setting of LogLevel that AddDebug outputs is a more Information, in the case of Trace / Debug not output.

When you start in the console, the log is filtered as the settings made in AddConsole is output.

The logging around to the other there is a function, such as Scope and EventId, but omitted because it is not an essential part of the logging. Function as a provider is poor by default, but because there is a scalable or combine the existing framework, I think that there is a need to take advantage of TraceListener.

Because we want as yourself go by pouring log in Azure EventHubs, I want to play and write the appropriate provider leveraging ILoggerProvider.

comments powered by Disqus
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.