Have Serilog get automatically the configuration

I just started using Serilog in a ASP.NET Core app, and I find it annoying that you cannot just use .UseSerilog() but one has to explicitly pass in the configuration

    .UseSerilog((hostingContext, loggerConfiguration) => loggerConfiguration
        .ReadFrom.Configuration(hostingContext.Configuration)
        .Enrich.FromLogContext()
        .WriteTo.Console())

Is there some technical matter that prevents the .UseSerilog to just work? Why do I need to tell serilog to read the configuration? Cannot it be done automatically?

Also, I think that the “early initialization” example is going against the standard convention of ASP.NET Core. The CreateDefaultBuilder already creates the configuration object exactly as done in the sample. I don’t see why you would need to do it “manually”. I think as it is explained, it’s misleading.

[nblumhardt]

@simonech Howdy!

Is there some technical matter that prevents the .UseSerilog to just work? Why do I need to tell serilog to read the configuration? Cannot it be done automatically?

No technical matter; it could be done. As @sungam3r points out, the current layering would need to be reconsidered, but there’s no fundamental reason not to consider it.

Some complications will inevitably arise around how to customize configuration reading, (“how do I use a different section name?”, “how do I turn it off?”, perhaps) - and there’s the question of bloating the package dependency graph for those who don’t use ReadFrom.Configuration(), so it mostly needs thought and time/attention, but hasn’t made it to the top of the list thus far.

Also, I think that the “early initialization” example is going against the standard convention of ASP.NET Core.

Yes, this is deliberate - the default ASP.NET Core logging setup doesn’t collect exceptions from host setup, which I think is a mistake, although opinions vary and we try to support both approaches equally well. The post at https://nblumhardt.com/2019/10/serilog-in-aspnetcore-3/ discusses some of this. Let’s keep this particular ticket focused on your suggestion RE automatic reading of configuration so we don’t end up off down that rabbit hole 😃

[nblumhardt]

I think we’re unlikely to tackle this in the immediate future, so closing, but will come back and review it if there’s a future opportunity to improve, here.