Could WebHostExtensions.Run() use Logging?

[gingters]

Hello,

I have an issue with WebHostExtensions.Run() using Console.WriteLine() instead of writing its log entries to an ILogger instance, just like this.

It seems pretty unintuitive that, after you already haved configured your logging etc. in the WebHostBuilder.Build() method, that the .Run() method after that should not be able to leverage this information.

So I would like to propose that the WebHostExtensions.Run() should try to resolve an ILogger from the host.Services just as it does with the hostingEnvironment and applicationLifetime, and use that if available. Only if there is no logger available it should fall back to writing to the Console directly.

What do you think about this? Could we make this happen?

[davidfowl]

How would you know if there's no logger available? Also these messages are for the developer. Do you have an actual issue with them being console writeline statements?

[cwe1ss]

I think it would be nice to have it sent to both. For remote loggers it would be an earlier "Hello World, I'm here" message. And I wouldn't remove the console output because it's a nice troubleshooting instrument e.g. in Service Fabric where you sometimes have to inspect console output etc.

[davidfowl]

The only problem is that by default you'd end up with this duplication of messages. Do you really think logging the bound end point information is useful for your logs? I can see the environment as the only thing being useful. The content root is a developer artifact as well.

If this is a purist argument, then I get it but the practical side of me says this won't add much value.

[cwe1ss]

hmm.. true! My scenario is just an early out-of-the-box "Application started" logging message. But that's obviously something that can easily be done as the first thing in Startup as well.

EDIT: Environment name would be nice in logging, yes.

[gingters]

The main issue is that these logs that are captured from the console are not as easily parsable as they could be, as these lines don't match the desired and configured console logger output format than all the other lines. This is desired for launching a service for automated tests and then simply capturing and analysing the console output instead of having to configure a certain file logger explicitely (which then would lack the environment and port information).

Also, knowing if no logging is available would be the case when no ILogger could be resolved?

[gingters]

Oh, and yes, if you deploy a command line tool that temporarily offers a web service, you actually don't want to print these lines in the the command prompt for the user. Wrapping that in something that calls mytool.exe > nul 2>&1 would just be a ugly workaround for that. It would be great if there would be a way to at least disable the WriteLines for production, as we could log environment and port (and even ContentRootPath or shutdown message if desired) easily by our own when required.

That would be less effort and more convenient than to duplicate the complete Run extension.

[davidfowl]

@gingters Then use Start() instead of Run

[davidfowl]

Also, knowing if no logging is available would be the case when no ILogger could be resolved?

No, that's not right. The logger can always be resolved, the producer and consumer of logs is completely decoupled.

[davidfowl]

How about we add a flag that says if hosting should prefer logging for this? That way we can just use that to determine if we should log or use console output?

[davidfowl]

We're going to move away from writing to the console when using the generic host