Setting up logging in Blazor

[nblumhardt]

Hi all!! Hope you're all having fun, hacking on such an interesting bit of code 😄

I spent a few hours last night experimenting with Serilog in Blazor, both to the local browser console and piped through the server using middleware. The code is in: https://github.com/nblumhardt/serilog-blazor.

There's a whole lot to explore in this space, but I thought I'd try to get in early with a bit of feedback on how it hangs together.

Some developers, me among them, will go to great lengths to get logging set up before any other application code executes. This makes it easier to debug startup failures, which are usually critical issues. You can see I've done that in the Blazor client demo here: https://github.com/nblumhardt/serilog-blazor/blob/master/SerilogBlazorDemo.Client/Program.cs#L12

Because the demo pipes client logs through the server, HTTP is needed; getting the base URI before the Blazor host is initialized took some hackiness: https://github.com/nblumhardt/serilog-blazor/blob/master/SerilogBlazorDemo.Client/Diagnostics/BrowserHttpSink.cs#L67 - it would be great if this could be properly supported by the Blazor API.

This echoes some of the problems with logging in ASP.NET Core, particularly the decision to put configuration (and thus logging setup) into DI. This ends up greatly expanding the amount of code that runs before logging is available, and thus the scope of potential failures that can't be properly logged. It would be great to avoid this in Blazor, by providing non-DI access to critical system services (like HTTP, mentioned above). Less-ergonomics/jumping-through-hoops would be acceptable, if it enabled bootstrapping logging ahead of anything else.

Hope this is at least food-for-thought, and good luck with it all! (Also, hope you have a chance to run the demo, it's quite compelling to see just how consistent the client/server experiences can be 😎 .)

[mv10-work]

This echoes some of the problems with logging in ASP.NET Core, particularly the decision to put configuration (and thus logging setup) into DI

I don't understand this decision at all. There are many important settings to configure in a real app during Program.cs / Main bootstrapping (ports, URLs, etc). For us this makes the convenience of CreateDefaultBuilder largely irrelevant.

That being said, I've noticed some builder delegates do supply configuration at this stage. I've been working with Microsoft Orleans recently and config is available through HostBuilderContext. I haven't had time to dig into how this works to determine if I can do something similar where context/config isn't already available in a similar way:

public static IHostBuilder ConfigureOrleansHost(this IHostBuilder hostBuilder)
{
    hostBuilder.UseOrleans((hostContext, siloBuilder) =>
    {
        var cfg = hostContext.Configuration;
        var connectionString = cfg.GetConnectionString(ConstConfig.ConnectionStringOrleans);
     ...etc

Related ... #9337

[pranavkm]

The hosting for WebAssembly is a bit different than the hosting for ASP.NET Core, and you should be able to get to things like the logger as part of Program.Main. While you still need to get it through the DI container, we think it has less friction than it's ASP.NET Core counterpart. If you have specific feedback about the builder, please file a new issue and we can discuss it further.