*Breaking change* ASP.NET Core Components telemetry requires `System.Diagnostics.Metrics.Meter.IsSupported` in .NET 11 preview

[Kielek]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Microsoft.AspNetCore.Components telemetry appears to be disabled in .NET 11 preview unless the System.Diagnostics.Metrics.Meter.IsSupported AppContext switch is explicitly enabled.

This changed with #65901, which added guards for both:

• ComponentsMetrics
• ComponentsActivitySource

using:

AppContext.TryGetSwitch("System.Diagnostics.Metrics.Meter.IsSupported", out var isSupported) ? isSupported : false;

This is problematic for OpenTelemetry instrumentation. OpenTelemetry.Instrumentation.AspNetCore listens to Microsoft.AspNetCore.Components for both metrics and traces:

• metrics: AddMeter("Microsoft.AspNetCore.Components") https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/1c4410fc297d02d448ce98783aeb70d6c5d51289/src/OpenTelemetry.Instrumentation.AspNetCore/AspNetCoreInstrumentationMeterProviderBuilderExtensions.cs#L57
• traces: AddSource("Microsoft.AspNetCore.Components") https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/1c4410fc297d02d448ce98783aeb70d6c5d51289/src/OpenTelemetry.Instrumentation.AspNetCore/AspNetCoreInstrumentationTracerProviderBuilderExtensions.cs#L150

However, in .NET 11 preview, those listeners are no longer enough. The application must also enable the AppContext switch before ASP.NET Core Components telemetry is initialized.

This is surprising for two reasons:

1. Component tracing is gated by a metrics switch.
2. The default differs from System.Diagnostics.Metrics.Meter.IsSupported, which defaults to true when the switch is not configured.

The issue was found while working on .NET 11 support for https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation.

Expected Behavior

Bring back previous behavior. Switch should not be needed.
It is important, because this https://learn.microsoft.com/en-us/aspnet/core/log-mon/metrics/built-in?view=aspnetcore-11.0 does not mention any other changes than only listening on this.

Steps To Reproduce

Create a Blazor/Razor Components app targeting .NET 11 preview and configure OpenTelemetry both for .NET 10 and .NET 11:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .AddSource("Microsoft.AspNetCore.Components")
            .AddConsoleExporter();
    })
    .WithMetrics(metrics =>
    {
        metrics
            .AddMeter("Microsoft.AspNetCore.Components")
            .AddMeter("Microsoft.AspNetCore.Components.Lifecycle")
            .AddConsoleExporter();
    });

Run the app and trigger component activity, for example navigation or event handling.

Observed behavior:

• No Microsoft.AspNetCore.Components traces are emitted.
• No Microsoft.AspNetCore.Components metrics are emitted.

Then add the switch very early in app startup:

AppContext.SetSwitch("System.Diagnostics.Metrics.Meter.IsSupported", true);

Observed behavior after enabling the switch:

• Microsoft.AspNetCore.Components telemetry is emitted.

Exceptions (if any)

No response

.NET Version

11.0.100-preview.4.26230.115

Anything else?

Switch name is strange, as it covers both metrics and traces.

[Kielek]

@JamesNK as you implemented this on the contrib repository.
@maraf, @pavelsavara as you were working on the problematic PR.

[github-actions]

Triage Summary

Area: area-blazor (issue relates to Microsoft.AspNetCore.Components telemetry, including ComponentsMetrics and ComponentsActivitySource which are part of the Components/Blazor infrastructure)

Type: bug (this is a regression where previously working telemetry behavior was broken by PR #65901 in .NET 11 preview, requiring an unexpected AppContext switch)

Regression Info

• Previously working version: .NET 10 and earlier
• Broken since: .NET 11 preview 4 (11.0.100-preview.4.26230.115)
• Behavior change: ASP.NET Core Components telemetry (both metrics and traces) is now disabled by default unless System.Diagnostics.Metrics.Meter.IsSupported AppContext switch is explicitly set to true. This breaks existing OpenTelemetry instrumentation that previously only needed to listen to the Microsoft.AspNetCore.Components meter and activity source.
• Root cause: PR [browser][wasm] Implement IL trimming for OTEL #65901 added guards that default to false when the switch is not set, which differs from the standard System.Diagnostics.Metrics.Meter.IsSupported behavior (which defaults to true).

Potential Duplicates

• None found

Notes

• This is a breaking change affecting OpenTelemetry users and should be documented or reverted
• The issue highlights two unexpected behaviors: (1) component tracing being gated by a metrics switch, and (2) the default differing from the standard BCL behavior
• The documentation at learn.microsoft.com does not mention this additional requirement

Generated by Issue Triage Agent for dotnet/aspnetcore for issue #66822 · ● 477.8K · ◷

[pavelsavara]

2. The default differs from `System.Diagnostics.Metrics.Meter.IsSupported`, which defaults to `true` when the switch is not configured.

I disabled it for Blazor WASM default size and performance.
The other feedback we get is that Component metrics/activities generate too much data and increase Azure bill on the server side.

I think we have few options

1. change the SDK default for System.Diagnostics.Metrics.Meter.IsSupported to true when <MetricsSupport> is not set.
2. change the default to false just for WASM
3. create new feature flag(s) dedicated for Components
4. have the .WithTracing() and .WithMetrics() to call AppContext.SetSwitch()

1. Component tracing is gated by a metrics switch.

We probably could introduce independent switch.

Then add the switch very early in app startup:
AppContext.SetSwitch("System.Diagnostics.Metrics.Meter.IsSupported", true);

Note I also implemented #66513 which caches the value of the feature switch.
That means feature switches should be switched ideally at compile time via MBuild switch such as
<MetricsSupport>true</MetricsSupport>, because calling AppContext.SetSwitch too late would have no effect.

Reasons is that AppContext.GetSwitch on each request leads to lock contention.