Add option to disable logging in sample Blazor app

[CoffeeFlux]

When publishing the Blazor sample, System.Extensions.Logging and System.Extensions.Logging.Abstractions are present in the output and appear to be held alive by DependencyInjection. It would be nice to ensure they can be linked out by someone attempting to maximize size reduction, even if that requires an extra flag to be set in the build configuration.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[SteveSandersonMS]

Logging is a feature of the default app template. Is this a proposal to remove that feature, or something more subtle?

[CoffeeFlux]

Is that feature in the template or Blazor itself? Is there a reason we need to log in the final published app? Apologies if this is silly; it's been a while since I filed this and don't remember the details.

[eerhardt]

I believe the intention here is to introduce a feature switch which allows for logging to be conditionally removed. All that should be necessary is to add an if around this code:

aspnetcore/src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHostBuilder.cs

Lines 249 to 252 in 85a6cb0

	Services.AddLogging(builder =>
	{
	builder.AddProvider(new WebAssemblyConsoleLoggerProvider(DefaultWebAssemblyJSRuntime.Instance));
	});

That would allow for the Microsoft.Extensions.Logging*.dll assemblies to be removed from the app (~18 KB .br compressed).

By default, we can keep the same behavior as we have now. But if someone wants to get their app as small as possible, this would enable them to remove these logging assemblies by flipping the feature switch.

[SteveSandersonMS]

@eerhardt The availability of the logger DI services is an assumption we make throughout various core components, such as <Router>. 3rd-party components will also freely rely on its presence since it's always been part of the mandatory minimal set and within ASP.NET Core circles it's generally assumed that any application is going to support logging.

Do you think it would be reasonable for us to consider adding a "no logging" option only if we get some clear feedback from customers that they want it? If almost nobody would realistically turn on such an option, it seems like the benefit is artificial at best, and would also impose a some disproportionate costs like us trying to account for the cases where logging isn't available.

Is there a reason we need to log in the final published app?

Yes, logging is a core feature of the framework. Developers issue log messages through ILogger from their own code, plus they have the ability to configure in production how much log detail they get out of framework code. People use this to diagnose issues in production.

The line we tread between "minimalist library" and "full-featured framework" is a subjective one. ASP.NET Core - and Blazor by extension - tries not to be at either extreme on the spectrum, and tries to provide enough configurability to suit enough people, but without so much that it's impossible to build an ecosystem because nothing can be taken for granted. As it stands, logging happens to be one of the things we've learned to treat as core, but anything can change if needed!

[eerhardt]

Do you think it would be reasonable for us to consider adding a "no logging" option only if we get some clear feedback from customers that they want it?

The idea is that if a customer wants their application as small as possible, they would turn this switch on. We would document it just like the others in https://docs.microsoft.com/en-us/aspnet/core/blazor/webassembly-performance-best-practices?view=aspnetcore-5.0#disable-unused-features.

and would also impose a some disproportionate costs like us trying to account for the cases where logging isn't available.

I think the ILogger would always be there for any code to use. Code that needs to log shouldn't need to be aware if logging was disabled or not. We would just strip builder.AddProvider(new WebAssemblyConsoleLoggerProvider(DefaultWebAssemblyJSRuntime.Instance)); and probably just add a NullLogger instead.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[mkArtakMSFT]

Hi. Thanks for contacting us.
We're closing this issue as there was not much community interest in this ask for quite a while now.
You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.