[jamescrosswell]

Closes #4931

Summary

Raises the OpenTelemetry floors on the two shipped packages, targeting version7:

Project	Package	Before	After
Sentry.OpenTelemetry	OpenTelemetry	1.6.0	1.12.0
Sentry.OpenTelemetry.Exporter	OpenTelemetry.Exporter.OpenTelemetryProtocol	1.10.0	1.12.0

Closes #4931

Rationale

Normally we target the oldest dependencies possible so consumers can pick whatever version they want.

However OpenTelemetry.Api 1.10.0, 1.11.0 and 1.11.1 are delisted from nuget.org (listed=false
on the registration feed), pulled deliberately over GHSA-8785-wc3w-h8q6. That advisory needs no opt-in — receiving a traceparent/tracestate header is enough, and it "impacts any application accessible over the web ... Even if an application does not explicitly use trace
context propagation."

OpenTelemetry.Exporter.OpenTelemetryProtocol 1.10.0 is itself still listed, so restore emits no warning at all while quietly resolving a dependency the ecosystem has hidden. The do-nothing path lands on the bad version silently, and
nothing tells anyone to override it.

Additionally:

• 1.11.0 and 1.11.1 are delisted for the same advisory.
• 1.11.1 and 1.11.2 pull Grpc.Core [2.44.0, 3.0.0) on net462 — the deprecated native gRPC
  library. 1.12.0 drops it again.

1.12.0 is the lowest floor that is both listed and free of Grpc.Core.

Note on the System.Net.Http reference

OpenTelemetry 1.12.0 no longer brings System.Net.Http in transitively on .NET Framework (1.6.0 did, via Microsoft.Extensions.Logging.Configuration). SentryPropagator uses HttpRequestMessage, so net462 failed with CS0246 until Sentry.OpenTelemetry referenced the framework assembly explicitly — the same pattern already in src/Sentry/Sentry.csproj.

Sentry.OpenTelemetry.Exporter doesn't need it: the OTLP exporter package declares System.Net.Http as a frameworkAssembly for net462.

Verified locally

• Both src projects build clean across all TFMs, including net462.
• Sentry.OpenTelemetry.Tests (44) and Sentry.OpenTelemetry.Exporter.Tests (59) pass on net8.0/net9.0/net10.0.
• dotnet publish test/Sentry.TrimTest -c Release -r osx-arm64 -p:NO_MOBILE=true (the Trim analysis
  CI job) succeeds with zero IL warnings — 1.12.0 keeps the trim-clean guarantee the old 1.6.0
  comment was protecting.
• The five OTel-consuming samples build with no NU warnings.
• Resolved graph on both projects is OpenTelemetry{,.Api,.Api.ProviderBuilderExtensions}/1.12.0
  plus OpenTelemetry.Exporter.OpenTelemetryProtocol/1.12.0, with no Grpc* or Google.Protobuf.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (version7@d589ac5). Learn more about missing BASE report.

Additional details and impacted files

@@             Coverage Diff             @@
##             version7    #5560   +/-   ##
===========================================
  Coverage            ?   74.66%           
===========================================
  Files               ?      515           
  Lines               ?    18907           
  Branches            ?     3690           
===========================================
  Hits                ?    14116           
  Misses              ?     3906           
  Partials            ?      885           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sentry]

Bug: The Sentry.OpenTelemetry.Exporter project is missing a required reference to System.Net.Http for .NET Framework targets, which will cause compilation to fail.
_{Severity: HIGH}

Suggested Fix

Add an explicit framework reference for System.Net.Http to Sentry.OpenTelemetry.Exporter.csproj for .NET Framework targets. This can be done by adding <Reference Include="System.Net.Http" /> inside an ItemGroup conditioned on $(TargetFrameworkIdentifier)' == '.NETFramework', mirroring the change made to Sentry.OpenTelemetry.csproj.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/Sentry.OpenTelemetry.Exporter/Sentry.OpenTelemetry.Exporter.csproj#L13-L22

Potential issue: The file `SentryPropagator.cs` is compiled by both the
`Sentry.OpenTelemetry` and `Sentry.OpenTelemetry.Exporter` projects. This file uses
`HttpRequestMessage`, which requires a reference to `System.Net.Http` when targeting
.NET Framework. While the pull request adds this reference to the `Sentry.OpenTelemetry`
project, it omits it from `Sentry.OpenTelemetry.Exporter.csproj`. This creates a fragile
build that relies on a transitive dependency from another package. If that transitive
dependency is not present, the `Sentry.OpenTelemetry.Exporter` project will fail to
compile for .NET Framework targets like `net462`.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[jamescrosswell]

Not a bug — Sentry.OpenTelemetry.Exporter compiles for net462 as-is.

The reference isn't inherited by accident; the package declares it. OpenTelemetry.Exporter.OpenTelemetryProtocol 1.12.0's nuspec contains:

<frameworkAssemblies>
  <frameworkAssembly assemblyName="System.Net.Http" targetFramework=".NETFramework4.6.2" />
</frameworkAssemblies>

which NuGet resolves into this project's net462 graph:

OpenTelemetry.Exporter.OpenTelemetryProtocol/1.12.0: ['System.Net.Http']

OpenTelemetry and OpenTelemetry.Api carry no frameworkAssemblies block at all, which is why Sentry.OpenTelemetry did fail with CS0246 and needed the explicit <Reference Include="System.Net.Http" />, while Sentry.OpenTelemetry.Exporter did not. The asymmetry is deliberate.

On the weaker form of the point — that depending on a package-supplied framework assembly is fragile — frameworkAssemblies is a declared part of a package's contract, no more fragile than its declared <dependencies>. If OpenTelemetry ever dropped that declaration, it would break loudly at compile time on whichever PR moved the floor, and the explicit reference could be added then with context. Adding it pre-emptively would be redundant build config guarding a scenario that can't fail silently.

[lucas-zimerman]

LGTM!