Discussion: Breaking Logging changes and new additions

[BrennanConroy]

The is the discussion issue for the announcement aspnet/Announcements#238.

[epignosisx]

In the old way of configuring logging, we could add to the Configure method additional services registered in DI that our logging provider would need. How can we achieve the same in the new style?

Fox example, in my app, I use Serilog, and I have a custom Enricher: WebEnricher, that would take care of logging of additional data like querystring. For that, I was injecting the IHttpContextAccessor in the Configure method and then constructing the WebEnricher with it.

public class WebEnricher : ILogEventEnricher
{
    public WebEnricher(IHttpContextAccessor httpContextAccessor) 
}

[epignosisx]

@BrennanConroy don't want to look pushy, but can you take a look at my comment above? Just trying to understand if we are losing use cases with the new approach.

[mgrishkov]

What's about non-web-hosted application? How should I use extension ConfigureLogging out of IWebHostBuilder?

[davidfowl]

What's about non-web-hosted application? How should I use extension ConfigureLogging out of IWebHostBuilder?

How does this change affect that? If you're in a non hosted web application who is creating the concrete LoggerFactory instance?

[davidfowl]

@epignosisx That scenario is genuinely broken and it's something we're going to look at fixing for preview2. The only work around I can think of right now would be to downcase ILoggerFactory to LoggerFactory and call AddProvider the same way you did before (but more hackily). Or by suppressing the deprecated warning.

We have plans to better integrate logging with DI when running in ASP.NET Core.

[mgrishkov]

My code:

Configuration = new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", false, true)
    .Build();
....
Services = new ServiceCollection();
Services.AddLogging()
    .AddOptions();
....
ServiceProvider = Services
                .BuildServiceProvider();
....
LoggerFactory = ServiceProvider.GetService<ILoggerFactory>();
LoggerFactory
    .AddDebug(LogLevel.Trace);

[davidfowl]

You're missing something there who added the ILoggerFactory to the container?

[mgrishkov]

Sorry. I use this code:

Services.AddLogging()
                .AddOptions();

I've fixed my code sample.

[cwe1ss]

@mgrishkov You would just do the following instead:

// Create your own logger factory
LoggerFactory loggerFactory = new LoggerFactory();
loggerFactory.AddDebug(LogLevel.Trace);

Services = new ServiceCollection();
Services
    // Add your own logger factory to DI
    .AddSingleton<ILoggerFactory>(loggerFactory)
    .AddLogging() // This adds the remaining interfaces (e.g. ILogger)
    .AddOptions();
....
ServiceProvider = Services.BuildServiceProvider();

@davidfowl This is a good example for why I thought #501 would have been nice. I think it's much more important now that people have to work with the concrete LoggerFactory type more often.

[mgrishkov]

Ok, thank you I'll check it.

[epignosisx]

Thanks @davidfowl. I'll keep eye for preview 2. Is this issue being tracked? Should I open an issue for better visibility?

[davidfowl]

Thanks @davidfowl. I'll keep eye for preview 2. Is this issue being tracked? Should I open an issue for better visibility?

Open an issue.