Roslyn analyzer: warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never called

[Evangelink]

Background

#8409 / #8930 fixed the misleading XML doc and README for AddOpenTelemetryProvider — calling it without configuring instrumentation and exporters produces no telemetry, and the docs now say so explicitly. That closes the documentation bug but doesn't catch users who reference the package and forget to wire it in their Main. Both the auto-generated entry point and explicit Main users (with or without AddSelfRegisteredExtensions) can fall into this trap.

The OTel extension cannot piggy-back on the standard TestingPlatformBuilderHook self-registration mechanism (the way AppInsights, TrxReport, CrashDump, Retry, … do) because AddOpenTelemetryProvider() with no delegates still produces no MTP telemetry and no exporter, so a no-arg hook would be useless. The wiring is intrinsically caller-supplied.

Proposal

Ship a Roslyn analyzer in Microsoft.Testing.Extensions.OpenTelemetry (analyzers/dotnet/cs/) that emits a warning when the package is referenced by an executable project (test host) but Microsoft.Testing.Extensions.OpenTelemetryProviderExtensions.AddOpenTelemetryProvider is never invoked in the compilation.

• Diagnostic id: MTPOTEL001 (TBD).
• Default severity: Warning.
• Title: OpenTelemetry extension is referenced but never configured.
• Message: The 'Microsoft.Testing.Extensions.OpenTelemetry' package is referenced but 'AddOpenTelemetryProvider' is never called. Wire it from your test host's Main (or AddSelfRegisteredExtensions equivalent) to enable OpenTelemetry, or remove the package reference.
• Suppressible per project via <NoWarn>MTPOTEL001</NoWarn> for the rare case where the package is referenced solely for AddTestingPlatformInstrumentation(TracerProviderBuilder) / AddTestingPlatformInstrumentation(MeterProviderBuilder) on a caller-owned OTel pipeline.
• Scope: only run on output-type Exe projects (or, more precisely, projects that reference Microsoft.Testing.Platform) to avoid noise in libraries that transit the dependency.

Why an analyzer rather than a runtime warning

A runtime warning (e.g. emitted from a startup hook) would also trip explicit-Main users who deliberately reference the package without enabling OTel — the same false-positive concern raised in the #8409 discussion. With an analyzer, that scenario has a clean, idiomatic .NET escape hatch (<NoWarn> / .editorconfig severity / #pragma warning disable) instead of forcing us to invent a bespoke opt-out property or attribute.

Out of scope

• Detecting whether an exporter was actually registered inside the withTracing / withMetrics delegate. That's a syntactic dead-end (the delegate body is arbitrary user code that can defer to runtime), and the docs/README change in Document that AddOpenTelemetryProvider does not register default instrumentation or exporters #8930 already covers that part of the contract.
• Generalising the analyzer to other extensions: most MTP extensions self-register cleanly, so this is OTel-specific for now. If a future extension hits the same pattern we can lift the analyzer into a shared infrastructure project.

Related

• [MTP Diagnostic Analysis] AddOpenTelemetryProvider defaults to a no-op despite documented default behavior #8409 — original bug report (docs/contract).
• Document that AddOpenTelemetryProvider does not register default instrumentation or exporters #8930 — docs-only fix that ships first.