[nagilson]

Follow-up to #56274.

Problem

The Azure Monitor exporter names its persistent storage sub directory by hashing instrumentationKey;userName;processName;AppContext.BaseDirectory. dotnet.dll and dotnet-aot have different base directories, so their telemetry lands in two separate directories.

The managed side runs less often, rarely drains its own backlog (it is too slow to actually have enough time to push data without adding significant exit lag), and that telemetry is lost.

Change

Azure added the Azure.Monitor.OpenTelemetry.Exporter.StorageSubDirectory AppContext value for us in Azure/azure-sdk-for-net#63337 (fixes Azure/azure-sdk-for-net#62997), released in Azure.Monitor.OpenTelemetry.Exporter 1.10.0. This PR updates the SDK to consume that official package. TelemetryClient sets the value to dotnet-cli. TelemetryClient.cs is compiled into both dotnet and dotnet-aot, so one line covers both entry points. The instrumentation key and user name still contribute to the hash, so different users and resources remain isolated.

• documentation/project-docs/telemetry.md describes the shared directory.
• New E2E test ItDrainsTelemetryPersistedByTheOtherEntryPoint, run in both directions: one entry point persists telemetry, then the other leases the same blob from the same directory to upload it. With the SetData line removed, both cases fail because the directories differ.

Validation

• PersistentStorageTelemetryE2ETests and TelemetryClientTests (33 tests) pass.
• Microsoft.DotNet.Cli.Telemetry.Tests passes.
• Manually confirmed that dotnet exec dotnet.dll --help and AOT dotnet --help write to the same sub directory.

Tactics

Summary

The Azure Monitor exporter derives its persistent storage subdirectory from a hash that includes AppContext.BaseDirectory, so dotnet.dll (managed) and dotnet-aot write telemetry to different directories. The managed side runs less often and rarely drains its backlog, so its persisted telemetry is lost. This PR bumps Azure.Monitor.OpenTelemetry.Exporter to 1.10.0 (eng/Versions.props), which supports the Azure.Monitor.OpenTelemetry.Exporter.StorageSubDirectory AppContext switch, and sets it to dotnet-cli in TelemetryClient.cs (compiled into both entry points). The change is small and confined to telemetry, and fits a servicing release because it recovers lost telemetry without affecting CLI functionality.

Customer Impact

Customers see no functional symptom. The impact is on SDK telemetry: data persisted by the managed CLI is stranded and never uploaded. This affects every install that uses both entry points, in the release this branch (release/11.0.1xx) ships. There is no user-facing workaround, and none is needed. Instrumentation key and user name still contribute to the hash, so users and resources stay isolated.

Regression?

Unknown — not enough information to determine origin. The PR is a follow-up to #56274 and fixes a gap in how the managed and AOT entry points share persistent storage.

Testing

• New E2E test ItDrainsTelemetryPersistedByTheOtherEntryPoint, run in both directions (managed→AOT and AOT→managed). Per the PR description, both cases fail when the SetData line is removed.
• PersistentStorageTelemetryE2ETests and TelemetryClientTests (33 tests) pass, as does Microsoft.DotNet.Cli.Telemetry.Tests, per the PR description.
• Manual check by the author: dotnet exec dotnet.dll --help and AOT dotnet --help write to the same subdirectory.
• Approved by baronfel; the Copilot reviewer reported 0 open findings. CI was started, and a /ba-g override was issued because Build Analysis appeared stuck.

Risk

Low. The change is about 70 lines across 4 files: one version bump, one AppContext.SetData call, a doc update and tests. The main risk is the dependency bump from the exporter, mitigated by the targeted E2E and unit tests. Another is that a newly named shared directory is read by both entry points. Both are covered by the bidirectional tests.

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[nagilson]

https://github.com/Azure/azure-sdk-for-net/releases?q=telemetry&expanded=true watching this for a new upload

[nagilson]

Seems good minus the revert commit. Whenever they release a fix, we can publish the PR.

[nagilson]

There's a new 7 day limit on updates - https://github.com/Azure/azure-sdk-for-net/releases?q=exporter&expanded=true it's now been a week after coordination.

[Copilot]

🟢 Approval recommended

The official exporter setting is correctly initialized for both entry points and covered by focused bidirectional tests.

0 open findings

What changed in this PR

Shares Azure Monitor telemetry persistence between managed and Native AOT CLI entry points.

Changes:

• Upgrades the Azure Monitor exporter to 1.10.0.
• Configures a shared dotnet-cli storage subdirectory.
• Adds bidirectional E2E coverage and documentation.

File	Description
eng/​Versions.props	Updates the exporter dependency.
src/​Cli/​dotnet/​Telemetry/​TelemetryClient.cs	Configures shared telemetry storage.
test/​dotnet.Tests/​TelemetryTests/​PersistentStorageTelemetryE2ETests.cs	Verifies cross-entry-point draining.
documentation/​project-docs/​telemetry.md	Documents shared storage behavior.

🧠 Review effort: Balanced

[baronfel]

cc @DamianEdwards for Aspire Telemetry, if you have a managed/naot side, or multi-process split, you might also want to do this.

I think this is less of a problem for Aspire because it is an actual CLI app, not a NAOT Library trying to behave like an app.

[nagilson]

/ba-g build analysis seems stuck

[nagilson]

/tactics