Consider reacting to Microsoft.Extensions.Logging changes

[ycrumeyrolle]

aspnet/Announcements#238
The AddApplicationInsights extensions method should be on the LoggerFactory class instead of the ILoggerFactory interface.
In addition, the IServiceProvider parameter is hard to provide with the new logging configuration pattern :

public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .ConfigureLogging(factory =>
        {
            factory.AddConsole();
            factory.AddDebug();
            factory.AddApplicationInsight(serviceProvider ?);
        }
        .etc...

    host.Run();
}

[ycrumeyrolle]

Related #451

[cwe1ss]

This will change again in preview2. Logging will then be configured via DI. This means that logger providers like Application Insights who need services for their providers can easily do that by just adding themselves to DI via something like this:

builder.Services.AddSingleton<ILoggerProvider, ApplicationInsightsLoggerProvider>();

See aspnet/Logging#626

[DamianEdwards]

The AI provider can't take a dependency on these changes without upping their ASP.NET Core dependencies to 2.0, however that means it won't work with 1.x projects. Unfortunately NuGet doesn't really provide a mechanism for making a clean split like this in packages, as ASP.NET Core 1.x and 2.x use the same TFMs (netstandardX).

The only real option is for the AI packages to move to a new major version (3.0) and up the dependencies there, then tell customers they should stay on the 2.x packages if using ASP.NET Core 1.x, and move to the 3.0 packages if they're using ASP.NET Core 2.x. But again, that's error prone and not a particularly great experience, so I'd advise against it until we feel the benefits of having AI use the new changes in 2.0 warrant it.

[cijothomas]

This was addressed with new Microsoft.Extesions.Logging.Applicationinsights package.,