Document that AddOpenTelemetryProvider does not register default instrumentation or exporters by Evangelink · Pull Request #8930 · microsoft/testfx

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Fixes#8409.

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Fixes#8409.

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Fixes#8409.

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Fixes#8409.

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Fixes#8409.

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Fixes#8409.

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

Amaury Levé (Evangelink) · 2026-06-08T13:41:05Z

Fixes#8409.

Problem

AddOpenTelemetryProvider documented that omitting withTracing / withMetrics would use "default OpenTelemetry settings", but it actually built empty TracerProvider / MeterProvider instances. The PACKAGE.md claim that the extension "instruments test execution with OpenTelemetry-compatible traces and metrics" was therefore not true for the zero-configuration path — builder.AddOpenTelemetryProvider(); produced no MTP telemetry.

Approach

Per the issue, option #2: keep runtime behavior under the caller's control and make the API contract honest. Auto-registering MTP instrumentation inside the provider was considered but rejected to preserve the (real, if niche) scenario of using this extension purely to manage the lifecycle of an OTel pipeline for application-only telemetry; the caller still needs a Program.cs to wire exporters either way, so the convenience gain was small.

OpenTelemetryProviderExtensions.cs: XML docs on AddOpenTelemetryProvider now state explicitly that no instrumentation or exporter is registered by default and that the caller must wire both via the delegates, including AddTestingPlatformInstrumentation() to subscribe to MTP. AddTestingPlatformInstrumentation docs describe both use sites (inside the delegates and on a TracerProviderBuilder / MeterProviderBuilder configured outside the helper).
PACKAGE.md: drops the misleading "instruments test execution" framing and spells out the wiring required to actually collect MTP telemetry.
samples/public/MTPOTel/Program.cs: adds a short comment summarising the contract.

No public API surface change, no runtime behavior change — docs and sample only.

Verification

Built the extension cleanly (Debug, all TFMs) — 0 warnings, 0 errors.

Copilot

Pull request overview

This PR fixes the zero-configuration behavior of the Microsoft.Testing.Platform (MTP) OpenTelemetry extension by ensuring MTP’s ActivitySource and Meter are automatically registered when AddOpenTelemetryProvider() is used, bringing runtime behavior in line with the documented contract (Fixes #8409).

Changes:

Auto-registers MTP tracing/metrics instrumentation (Microsoft.Testing.Platform) inside OpenTelemetryProvider prior to invoking user configuration delegates.
Updates XML docs and package documentation to clarify the new contract (instrumentation auto-wired; exporters still caller-configured).
Simplifies the public sample by removing redundant AddTestingPlatformInstrumentation() calls.

Show a summary per file

File	Description
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProvider.cs	Adds `.AddSource(...)` and `.AddMeter(...)` by default so zero-config calls actually instrument MTP telemetry.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs	Updates XML docs to reflect auto-wiring and clarify what callers still must configure.
src/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md	Updates package docs to describe exporter responsibility and the zero-config behavior more accurately.
samples/public/MTPOTel/Program.cs	Removes redundant instrumentation calls to demonstrate the simplified API surface.

Copilot's findings

Files reviewed: 4/4 changed files
Comments generated: 2

…TelemetryProvider Fixesmicrosoft#8409. `AddOpenTelemetryProvider` documented that omitting the delegates would use "default OpenTelemetry settings", but in practice it built empty `TracerProvider` / `MeterProvider` instances and the package README claimed it instruments test execution out of the box - neither of which matches reality. Rather than auto-registering MTP sources (which would also prevent callers from hosting an OTel pipeline through this extension for app-only telemetry), this change keeps full control in the caller's hands and makes the API contract honest: - XML docs on `AddOpenTelemetryProvider` now state explicitly that no instrumentation or exporter is registered by default, and that the caller must wire both via the `withTracing` / `withMetrics` delegates. - `AddTestingPlatformInstrumentation` docs describe both use sites (from inside the delegates and from a builder configured outside the helper). - PACKAGE.md drops the misleading "instruments test execution" wording and spells out the wiring required to actually collect MTP telemetry. - The MTPOTel sample gets a comment summarising the contract. No public API surface change, no runtime behavior change. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Amaury Levé (Evangelink) · 2026-06-08T13:55:27Z

Filed #8931 to track the Roslyn analyzer follow-up (warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never invoked). Keeping this PR scoped to the docs/contract fix per the discussion.

CopilotAI review requested due to automatic review settings June 8, 2026 13:41

Copilotstarted reviewing on behalf of Amaury Levé (Evangelink)June 8, 2026 13:41 View session

CopilotAI reviewed Jun 8, 2026
View reviewed changes

Comment threadsrc/Platform/Microsoft.Testing.Extensions.OpenTelemetry/OpenTelemetryProviderExtensions.cs Outdated
Comment threadsrc/Platform/Microsoft.Testing.Extensions.OpenTelemetry/PACKAGE.md Outdated

Amaury Levé (Evangelink)force-pushed the dev/amauryleve/fix-otel-default-instrumentation branch from 7630129 to 59104d9Compare June 8, 2026 13:52

Amaury Levé (Evangelink) changed the title ~~Auto-register MTP instrumentation in AddOpenTelemetryProvider~~Document required MTP instrumentation and exporter wiring for AddOpenTelemetryProviderJun 8, 2026

Amaury Levé (Evangelink) mentioned this pull request Jun 8, 2026
Roslyn analyzer: warn when Microsoft.Testing.Extensions.OpenTelemetry is referenced but AddOpenTelemetryProvider is never called #8931
Open

Amaury Levé (Evangelink) changed the title ~~Document required MTP instrumentation and exporter wiring for AddOpenTelemetryProvider~~Document that AddOpenTelemetryProvider does not register default instrumentation or exportersJun 8, 2026

Amaury Levé (Evangelink) merged commit 15041b8 into microsoft:mainJun 9, 2026
28 checks passed

Amaury Levé (Evangelink) deleted the dev/amauryleve/fix-otel-default-instrumentation branch June 9, 2026 07:54