Bump Azure.Core and Azure.Monitor.OpenTelemetry.Exporter

[dependabot]

Updated Azure.Core from 1.60.0 to 1.62.0.

Release notes

Sourced from Azure.Core's releases.

1.62.0

1.62.0 (2026-08-20)

Features Added

• Added experimental (SCME0002) AzureCredentialResolver.Default public static property so standalone callers can share the process-wide credential cache used by DI-resolved paths.
• AzureCredentialResolver now resolves every ChainedTokenCredential Sources[] entry through the active resolver chain, so any registered CredentialResolver (built-in, broker, or third-party) can claim or override an entry. Entries are constructed as chained, so transient failures surface as CredentialUnavailableException and the chain falls through.

Breaking Changes

• AzureCredentialResolver now resolves a top-level single source (e.g. CredentialSource: AzureCliCredential) to the concrete credential type (AzureCliCredential) rather than a DefaultAzureCredential wrapper. Construction is unchanged (it uses the same DefaultAzureCredentialFactory helpers) — only the returned type differs; callers using CredentialSettings.TokenProvider as a TokenCredential are unaffected.
• AzureCredentialResolver no longer claims top-level BrokerCredential sections (canonical name or broker alias); they now require BrokerCredentialResolver from Azure.Identity.Broker 1.7.0+ (e.g. via AddBrokerCredentialResolver()). BrokerCredential entries nested inside a ChainedTokenCredential continue to resolve. Note: if BrokerCredentialResolver from Azure.Identity.Broker 1.7.0 is registered ahead of AzureCredentialResolver, a nested BrokerCredential entry is currently built as non-chained, so it may surface AuthenticationFailedException and abort the chain instead of falling through to the next entry. Without a broker resolver registered, the built-in chain path builds the broker entry as chained (correct fall-through). A future Azure.Identity.Broker release will make its resolver honor chained semantics for nested entries.

Commits viewable in compare view.

Updated Azure.Monitor.OpenTelemetry.Exporter from 1.8.3 to 1.9.0.

Release notes

Sourced from Azure.Monitor.OpenTelemetry.Exporter's releases.

1.9.0

1.9.0 (2026-09-04)

Features Added

• Add support for project id attributes propagation
  (#​62052)

• Shutting down a provider (including Dispose()) now writes pending telemetry to offline storage and uploads it in the background instead of blocking on ingestion. Short-lived applications such as CLI tools previously lost this telemetry, because they exit before a transmission completes; the telemetry is now durable before exit, and delivery is completed by a background drain in this or a subsequent run. ForceFlush is unchanged by default and can be opted in with the Azure.Monitor.OpenTelemetry.Exporter.PersistOnForceFlush AppContext switch, which applies to traces and logs only: a metric reader cannot distinguish a caller's flush from its periodic collection, so metric ForceFlush always transmits. The previous behavior can be restored with the Azure.Monitor.OpenTelemetry.Exporter.DisablePersistOnShutdown AppContext switch.
  (#​61818)

• How long shutdown waits for that background drain can now be set through the Azure.Monitor.OpenTelemetry.Exporter.ShutdownDrainBudgetMilliseconds AppContext data value, using either AppContext.SetData or a runtimeconfig.json configProperty. Dispose() passes a finite timeout, so by default part of that window is spent delivering telemetry and process exit tracks ingestion latency. Short-lived applications should set this to 0, which makes exit cost only the file write: measured at 2.7 ms regardless of ingestion latency, against 2011 ms with a two second ingestion delay. The default is unchanged, so long-running services keep delivering their final batch within the window Dispose() allows. A single-run CI job, where no later run exists to drain storage, should not raise this value but set the Azure.Monitor.OpenTelemetry.Exporter.DisablePersistOnShutdown switch with a bounded Retry.NetworkTimeout: raising the budget cannot guarantee delivery, because Shutdown() waits on the drain for no time at all and Dispose() is capped by the five second grace period OpenTelemetry allows it.
  (#​62340)

Bugs Fixed

• Telemetry left in offline storage by a process that exited during a transmission is no longer stranded permanently. A leased blob is renamed so that it matches neither the storage provider's blob enumeration nor its retention sweep, and the provider only reclaims those leases on a two minute maintenance timer that a short-lived process never reaches. Expired leases are now reclaimed when storage is drained.
  (#​61818)

• Offline storage is now drained shortly after startup rather than only after the process has been running for two minutes, so telemetry persisted by a previous run is uploaded even when no single run is long-lived.
  (#​61818)

• Telemetry is no longer dropped when the offline storage directory reaches its size cap. The oldest stored telemetry is evicted to make room.
  (#​61818)

• Statsbeat no longer holds up process exit. It exports once more as its meter provider is disposed, which put an ingestion round trip on the exit path; that final export now runs in the background, and its network timeout is bounded at five seconds rather than the pipeline default of 100 seconds. The customer SDK stats meter provider is instead left to live for the process lifetime, so it never exports on the exit path at all; its stats are delivered by its own periodic reader.
  (#​62340)

• Log fields are now culture-invariant. (#​61996)

• Added the telemetrySuccess dimension to Item_Dropped_Count for request and dependency telemetry.
  (#​62081)

Other Changes

• Updated OpenTelemetry dependencies to 1.18.0 and OpenTelemetry.PersistentStorage.FileSystem to 1.1.1.
  (#​62698)

• Improved activity conversion performance by reading recognized attributes from a fixed index instead of scanning the tag list for each one. Every span shape converts faster, by about a third for spans carrying Application Insights override attributes, and each conversion rents fewer pooled buffers. Standard metrics no longer collect the tags they never read.
  (#​62614)

  • Fixed pooled tag buffers being leaked whenever converting an activity failed, and retaining tag keys and values after being returned to the pool.
  • Fixed the buffer rent size being process-wide mutable state written without synchronization.
  • Fixed an activity tag with a null key dropping the remaining tags from custom properties.
  • Removed two attribute lookups that could never match. http.server_name and server.socket.address are still exported as custom properties, unchanged.

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)