Bump OpenTelemetry packages in Aspire ServiceDefaults template

[jfversluis]

Bump OpenTelemetry packages to latest stable versions in the maui-aspire-servicedefaults template:

• OpenTelemetry.Exporter.OpenTelemetryProtocol: 1.9.0 to 1.15.3
• OpenTelemetry.Extensions.Hosting: 1.9.0 to 1.15.3
• OpenTelemetry.Instrumentation.Http: 1.9.0 to 1.15.1
• OpenTelemetry.Instrumentation.Runtime: 1.9.0 to 1.15.1

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35333

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35333"

[Copilot]

Pull request overview

Updates the maui-aspire-servicedefaults template’s OpenTelemetry dependencies to newer stable versions, keeping the Aspire ServiceDefaults template aligned with current OpenTelemetry packages.

Changes:

• Bump OpenTelemetry.Exporter.OpenTelemetryProtocol and OpenTelemetry.Extensions.Hosting from 1.9.0 to 1.15.3.
• Bump OpenTelemetry.Instrumentation.Http and OpenTelemetry.Instrumentation.Runtime from 1.9.0 to 1.15.1.

[MauiBot]

🤖 AI Summary

👋 @jfversluis — new AI review results are available. Please review the latest session below.

📊 Review Session — 08b1bc5 · Bump OpenTelemetry packages in Aspire ServiceDefaults template · 2026-05-07 12:05 UTC

---

🚦 Gate — Test Before & After Fix

---

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent.

---

🧪 UI Tests — Category Detection

---

No UI test categories needed for this PR (no UI-relevant changes).

---

🔍 Pre-Flight — Context & Validation

---

Issue: N/A (no linked issue — direct maintainer version bump)
PR: #35333 - Bump OpenTelemetry packages in Aspire ServiceDefaults template
Platforms Affected: All (template change, affects project creation)
Files Changed: 1 implementation, 0 test

Key Findings

• Simple version bump of 4 OpenTelemetry packages in maui-aspire-servicedefaults template
• No linked issue — author (jfversluis, repository maintainer) initiated directly
• Packages updated: OpenTelemetry.Exporter.OpenTelemetryProtocol, OpenTelemetry.Extensions.Hosting, OpenTelemetry.Instrumentation.Http, OpenTelemetry.Instrumentation.Runtime
• Version jump from 1.9.0 → 1.15.3 / 1.15.1 (intentional split — packages have different release cadences)
• Microsoft.Extensions.Http.Resilience (9.0.0) and Microsoft.Extensions.ServiceDiscovery (9.0.0) correctly left unchanged (Aspire/MS packages versioned by .NET release)
• Microsoft.Maui.Core correctly uses $(MauiVersion) variable
• Template code (Extensions.cs) uses AddHttpClientInstrumentation(), AddRuntimeInstrumentation(), UseOtlpExporter() — APIs that remain stable through OTel 1.15.x
• Gate: ⚠️ SKIPPED — no tests detected in this PR (expected for a template .csproj-only change)

Code Review Summary

Verdict: LGTM
Confidence: high
Errors: 0 | Warnings: 1 | Suggestions: 1

Key code review findings:

• ⚠️ src/Templates/src/templates/maui-aspire-servicedefaults/MauiAspire.1.ServiceDefaults.csproj:14-17 — Version split between 1.15.3 and 1.15.1 across packages is intentional per OTel release cadence but should be documented or verified against a compatibility matrix to avoid future confusion.
• 💡 Consider extracting OpenTelemetry version to a central MSBuild property (e.g., $(OpenTelemetryVersion)) to reduce maintenance burden — currently each of the 4 packages has an independently pinned version with no cross-reference.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #35333	Hard-coded version bump of 4 OTel packages to 1.15.x	⚠️ SKIPPED (Gate)	MauiAspire.1.ServiceDefaults.csproj	Original PR, already merged

---

🔬 Code Review — Deep Analysis

---

Code Review — PR #35333

Independent Assessment

What this changes: Bumps four OpenTelemetry NuGet package references in the maui-aspire-servicedefaults template from version 1.9.0 to their latest stable releases (1.15.3 for core packages; 1.15.1 for instrumentation packages).

Inferred motivation: The OpenTelemetry packages were pinned to 1.9.0, which is ~6 minor releases behind current stable. The bump likely addresses security advisories, breaking-API removals, or simply keeping the generated template up-to-date so new Aspire users don't start on stale dependencies.

Is the approach sound? Yes. These are all third-party packages from the OpenTelemetry .NET project, managed independently from the .NET SDK version. Bumping them in the template csproj is the correct place to do this — there is no central Directory.Packages.props or Versions.props for template dependencies; they are intentionally pinned per-template.

---

Reconciliation with PR Narrative

Author claims: "Bump OpenTelemetry packages to latest stable versions in the maui-aspire-servicedefaults template." Lists each package and its old → new version.

Agreement: Fully matches independent assessment. The two pairs of differing patch versions (1.15.3 for OpenTelemetryProtocol/Extensions.Hosting vs 1.15.1 for Instrumentation.Http/Instrumentation.Runtime) are consistent with how the OTel .NET project ships: core and instrumentation packages have independent release cadences and version numbers. This is not a mistake.

---

Findings

No ❌ Error or ⚠️ Warning findings.

💡 Suggestion — Microsoft.Extensions.Http.Resilience and Microsoft.Extensions.ServiceDiscovery were not bumped

src/Templates/src/templates/maui-aspire-servicedefaults/MauiAspire.1.ServiceDefaults.csproj lines 11–12 still reference Version="9.0.0" for those two packages. This is almost certainly intentional (they are .NET 9–aligned Microsoft packages versioned with the runtime, not independently), but worth confirming. If a .NET 10 workload is the target for this template, the versions may need to be revisited when those packages receive a .NET 10 release.

---

Dimension Walk

Dimension	Status	Notes
Build & MSBuild	✅	No new third-party feeds added; packages resolve via dotnet-public which mirrors nuget.org. No auto-generated files committed.
Regression Prevention	✅	Integration tests for WindowsTemplates passed in CI, verifying the template compiles and runs with the new package versions.
Backward Compatibility	✅	Template consumers who scaffold a new project will receive newer OTel packages. There are no known breaking changes between 1.9.x and 1.15.x for the APIs used (AddOpenTelemetry, UseOtlpExporter, AddHttpClientInstrumentation, AddRuntimeInstrumentation).
Logic and Correctness	✅	The API surface used in Extensions.cs (AddOpenTelemetry, WithMetrics, WithTracing, UseOtlpExporter) is stable across the bumped range.
Public API Surface	N/A	No public MAUI API changes.
All other dimensions	N/A	No handler, layout, platform, or XAML code changed.

---

CI Status

All CI checks pass (as of the time of review):

• Build Windows/macOS (Debug + Release) ✅
• Pack Windows/macOS ✅
• Helix Unit Tests Windows (Debug + Release) ✅
• Integration Tests (AOT, Blazor, Build, MultiProject, Samples, WindowsTemplates) ✅
• All iOS integration test legs ✅

---

Devil's Advocate

On the version split (1.15.3 vs 1.15.1): Could this be a mistake — should all four packages be at the same version? No. In the OpenTelemetry .NET project, instrumentation packages (Instrumentation.Http, Instrumentation.Runtime) are released separately from the core SDK packages and have their own latest stable versions. Using the highest available stable version per package is the correct approach.

Could the Extensions.cs file need API updates for 1.15.x? Checked the file — it uses only stable, long-lived extension methods (AddOpenTelemetry, UseOtlpExporter, AddHttpClientInstrumentation, AddRuntimeInstrumentation). None of these were changed in a breaking way across the 1.9 → 1.15 range.

Is there a risk the new package versions pull in incompatible transitive dependencies? The full integration tests (including RunOniOS, RunOnAndroid, Blazor) all passed, which provides strong empirical confidence here.

Self-merge concern (process, not code): The PR was authored and merged by the same team member (jfversluis) without an explicit reviewer. For a mechanical dependency bump with all-green CI, this is low-risk, but teams that enforce a 2-eye rule should be aware.

---

Verdict: LGTM

Confidence: high

Summary: This is a straightforward, correct version bump of four OpenTelemetry packages in the Aspire ServiceDefaults template. All package versions are the current stable releases, the version split between core and instrumentation packages is intentional and correct, all CI checks pass (including integration tests that validate the template), and the Extensions.cs API usage is compatible across the version range. No code issues found.

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #35333	Hard-coded 1.15.3/1.15.1 OTel version split (correct per release cadence)	⚠️ SKIPPED (Gate — template-only, no executable tests)	1 file	Original PR, LGTM from expert review
1	try-fix-1 (claude-opus-4.6)	Centralized MSBuild properties $(OpenTelemetryVersion) + $(OpenTelemetryInstrumentationVersion)	✅ PASS (XML valid)	1 file	Adds complexity; requires 2 new properties inline
2	try-fix-2 (claude-sonnet-4.6)	Uniform 1.15.1 for all 4 packages	✅ PASS (XML valid)	1 file	Suboptimal — pins Exporter/Hosting to older patch versions
3	try-fix-3 (gpt-5.3-codex)	Bounded version ranges [1.15.3,2.0.0) / [1.15.1,2.0.0)	✅ PASS (XML valid)	1 file	Non-standard for MAUI templates; templates use pinned versions
4	try-fix-4 (gpt-5.5)	PR's 1.15.3/1.15.1 + inline XML comments documenting OTel cadence split	✅ PASS (XML valid)	1 file (+ unintended ci-copilot.yml dirty worktree — reverted)	Minor documentation improvement; same functional result as PR

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	No	"NO NEW IDEAS — space well-covered by 4 attempts and PR's approach"

Exhausted: Yes
Selected Fix: PR's fix — correct, minimal, LGTM (high confidence), all CI green, follows template version-pinning convention.

---

📋 Report — Final Recommendation

---

✅ Final Recommendation: APPROVE

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	1 changed file (template .csproj); no linked issue; author is repo maintainer
Code Review	LGTM (high)	0 errors, 0 warnings, 1 suggestion (💡 centralized version management)
Gate	⚠️ SKIPPED	No tests detected — template-only .csproj change with no executable test coverage
Try-Fix	✅ COMPLETE	4 attempts, all passing XML validation; cross-pollination exhausted after round 2
Report	✅ COMPLETE

Code Review Impact on Try-Fix

The LGTM verdict (high confidence, 0 errors) confirmed the PR's version split is correct. The single 💡 suggestion (centralized version management) directly inspired try-fix-1 and influenced try-fix-4. No error-level findings means no model was forced down an error-correction path — all four models instead explored genuinely orthogonal strategies (centralization, uniformity, version ranges, documentation). None of the alternatives improved on correctness or simplicity relative to the PR's fix.

Summary

PR #35333 is a correct, minimal version bump of four OpenTelemetry packages in the maui-aspire-servicedefaults template from the stale 1.9.0 to current stable releases (1.15.3 / 1.15.1). The expert code review found no errors or warnings. All CI integration tests — including Android, iOS, Windows Templates, Blazor, and AOT legs — are green. All four try-fix alternatives either introduced unnecessary complexity or were inferior to the PR's approach.

Root Cause

The four OpenTelemetry packages were pinned at 1.9.0, six minor releases behind the current stable. No linked issue — this is a proactive dependency maintenance change by the repository maintainer. The intentional version split (1.15.3 for core/exporter/hosting, 1.15.1 for instrumentation) correctly reflects OpenTelemetry's independent release cadences for its sub-packages.

Fix Quality

The PR's fix is of high quality: it touches exactly one file, makes the minimum necessary change, and uses verified-correct versions. The Extensions.cs API surface (AddHttpClientInstrumentation, AddRuntimeInstrumentation, UseOtlpExporter) is fully compatible across the 1.9.0–1.15.x range with no breaking changes. The Microsoft.Extensions.* packages (9.0.0) are correctly left unchanged as they are versioned with the .NET runtime, not the OTel release cycle.

---