[Blazor] Consider enabling MetricsSupport and EventSourceSupport by default for WebAssembly

[javiercn]

Summary

Consider enabling MetricsSupport and EventSourceSupport MSBuild properties by default for Blazor WebAssembly projects to support OpenTelemetry metrics instrumentation out of the box.

Background

Currently, to enable OpenTelemetry metrics in Blazor WebAssembly, developers must manually add MSBuild properties to their .csproj:

<PropertyGroup>
    <!-- Enable WebAssembly diagnostics for OpenTelemetry metrics -->
    <!-- See: https://learn.microsoft.com/aspnet/core/blazor/performance/webassembly-event-pipe-diagnostics -->
    <MetricsSupport>true</MetricsSupport>
    <EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>

Without these properties, runtime instrumentation and metrics don't work in WebAssembly, making Aspire integration incomplete.

Proposal

Consider enabling these properties by default in the Blazor WebAssembly SDK, similar to how other diagnostic features are enabled by default in ASP.NET Core projects.

Options

1. Enable by default for all WASM projects - Simplest, but may have size/performance implications
2. Enable by default when OpenTelemetry packages are referenced - Conditional enablement
3. Enable by default in Aspire-integrated projects - Scoped to Aspire scenarios only

Considerations

• App size impact: These properties may increase the final WASM bundle size
• Performance: Need to measure any runtime overhead
• Discoverability: Currently, developers often don't know these are required until metrics don't work

Documentation

• Blazor WebAssembly EventPipe diagnostics
• Blazor metrics and tracing

Related Issues

• Support hosted services in WebAssemblyHost #63637 - IHostedService support in WebAssembly

Part of .NET 11.0 Blazor + Aspire integration improvements

[pavelsavara]

It would be easier to decide this after we know the size/perf impact. My preference is 2) or 3).

I strongly dislike 1). Rather I think we will need to spend significant effort on trimming Blazor WASM after we switch to CoreCLR to stay comparable to Net10 on Mono.

[javiercn]

It would be easier to decide this after we know the size/perf impact. My preference is 2) or 3).

I strongly dislike 1). Rather I think we will need to spend significant effort on trimming Blazor WASM after we switch to CoreCLR to stay comparable to Net10 on Mono.

We can't really do 2 or 3. 3 is not really a thing (there's no way to scope this to aspire) and 2 would not be up to us (the open telemetry package would need to turn this on via a build props/targets file.

I don't believe requiring to opt-in on all the features because of size concerns is going to be the right trade-off. Even with a feature on/off like this, it won't represent a significant change relative to the size of actual webassembly apps out there (in other words, this change won't move the needle for any real wasm app) and having to add an extra gesture to enable this adds a friction that we don't want for a mainline scenario.

Our model should lean towards having a flag (which we already do) and letting users configure such flags to further trim the app.

[danroth27]

@javiercn Is this expected to land as part of #64890 for Preview 6??