.NET Aspire is stuck on OpenTelemetry 1.9.0

[eerhardt]

We haven't updated our dependeny on OpenTelemetry past 1.9.0 because 1.10.0 introduces dependencies that "lift" assemblies out of the shared framework. See [bug] targets other than net9.0 shouldn't be forced to use 9.0 dependencies (open-telemetry/opentelemetry-dotnet#5973) for more information.

We should decide what to do with this dependency. The major consumer of these packages is our templates in the ServiceDefaults project.

1. Should we upgrade to the new version even though we know it will "lift" Microsoft.Extensions.*, System.Diagnostics.DiagnosticsSource, • System.IO.Pipelines, System.Text.Encodings.Web, and System.Text.Json assemblies out of the shared framework?

2. Should we stay on the 1.9.0 version, and customers can update to the new versions if they want?

3. Should we split based on the TFM, and only use the new version if the app is targeting net9.0?

cc @joperezr @DamianEdwards @samsp-msft

[hdost]

Might be worth talking to some of your coworkers about fixing the OTel upstream side 🤷‍♂️.

[DamianEdwards]

Should we split based on the TFM, and only use the new version if the app is targeting net9.0?

These seems like a reasonable thing to do as we can do it in the template source so new projects on net9.0 get OTel >1.9.0 and net8.0 gets 1.9.0.

[sebastienros]

+1 on splitting based on the TFM

In this case the split is not too disruptive either (a few conditionals in code)

[DamianEdwards]

@eerhardt should we do the template fix to bump the OTel versions to latest when targeting net9.0 in 9.2?

[eerhardt]

@eerhardt should we do the template fix to bump the OTel versions to latest when targeting net9.0 in 9.2?

We can. It wouldn't hurt to update to the latest when you are targeting net9.0.

[DamianEdwards]

Version 1.14.0 of OpenTelemetry was just released and it fixes the lifting of packages on older TFMs:

We can now update our packages and templates to always bring in version 1.14.0 of the OTel packages for all TFMs!