[bug] targets other than net9.0 shouldn't be forced to use 9.0 dependencies

[paulomorgado]

Package

OpenTelemetry

Package Version

Versions 1.10.0 and those that take dependencies on it.

Runtime Version

net8.0, netstandard2.1, netstandard2.0, net462

Description

.NET 8.0 and the libraries tied to it will be supported until November 10, 2026 while .NET 9.0 and the libraries tied to it May 12, 2026.

Forcing users that want or need to be on the long term support channel to move to .NET 9.0 will expose them to possible breaking changings now and, on May 12, 2026 and November 10, 2026.

Given that OpenTelemetry is a cross-cutting concern and touches every application and service, forcing .NET 9.0 libraries on users that want or need to be on the long term support channel will prevent them from using the latest OpenTelemetry libraries.

Steps to Reproduce

Create an Aspire starter application targeting .NET 8.0 and upgrade OpenTelemetry components to the latest versions.

Expected Result

.NET 9.0 libraries is not forced upon the services.

Actual Result

.NET 9.0 libraries is forced upon the services.

Additional Context

I'm willing to send a PR to fix this.

[martinjt]

There's a lot of context here that's important to understand. I'm sure that others will provide a bit more deeper analysis.

At a top level, there are some new APIs in .NET that we require in order to achieve compatibility with the spec. There are around the new Metrics functionality in .NET 9, which is linked to the Diagnostics libraries. Without those, we wouldn't be able to support the required functionality, which is ultimately the reason we've had to drop support for .NET 6.

The System.Diagnostics 9.x libraries work in .NET 8 solution, so they won't need to upgrade to .NET 9. Therefore people will be able to be on the LTS of .NET, and benefit from the new libraries.

[vladislav-prishchepa]

OpenTelemetry always uses latest System.Diagnostics library because it utilizes its newly added API, it's seems OK - the diagnostics API is very stable and it's required to implement OTEL features. But for Microsoft.Extensions.* it's probably better to use <FrameworkReference Include="Microsoft.AspNetCore.App /> as suggested by MS docs (https://learn.microsoft.com//aspnet/core/fundamentals/target-aspnetcore?view=aspnetcore-9.0&tabs=visual-studio#use-the-aspnet-core-shared-framework) because it helps to avoid some breaking changes like 8.0.x regression with keyed services + IServiceCollection introspection in app/3rd-party libraries (fixed in latest 8.0.x releases).

[paulomorgado]

I know Microsoft.Extensions.* and System.Diagnostics.* version 9 can be used on .NET 8.0, but there's a supportability issue you are imposing on users that you can't do.

.NET 8.0 didn't change to use .NET 9.0 libraries targeting .NET 8.0 and there are reasons for that.

I suspect you'll change this very soon.

[paulomorgado]

@davidfowl, what are your plans regarding this and Aspire ServiceDefaults? Will .NET 9.0 libraries be forced upon users?

[martinjt]

There will be things that will have to change since you can't use the new Meter functionality without the Diagnostics information.

What I would imagine is that 99.9% of users will not notice anything. They'll pull in the latest OpenTelemetry and that will pull in the latest System.Diagnostics and everything will work. It's rare, in my experience, for someone to reference System.Diagnostics directly, and even if they do, it will resolve to the latest.

I can't really see a situation where this would be an issue, even in security conscious organisations (which I work with regularly). The only ones affected by this change are the .NET 6 users who can't upgrade to .NET 8.

[paulomorgado]

OK! I see you have no idea of the impact of this. When I have time I'll post here the dependency graph.

[martinjt]

I'd be happy to hear about what issues you see with this, we've spent a lot of time discussing this and working how we ensure we don't end up in the same situation we've had previously.

I worked through a tonne of scenarios prior to very long discussion the SIG had on how to do it, and .NET 6 is the only scenario that actually becomes an issue.

To be clear, Aspire.ServiceDefaults wouldn't need to take a dependency directly System.Diagnostics 9.0.0.0, I don't think it takes a direct dependency on 8 right now (I'm currently updating to check that). It will take an indirect dependency on that by taking OpenTelemetry 1.10 (released yesterday), it will also take that dependency when it takes on some of the instrumentations that need access to the new Meter APIs.

None of that, from what we investigated, would stop someone staying on 8.0.0.0. Even In-Process functions won't be an issue since they're already stuck on the previous versions of Otel.

So if you have a situation you can articulate where there is an issue, we can absolutely look into it, but we've spent a tonne of time working this out and didn't find anything that would be considered insurmountable at an organisation level, unless they're in a mode where they can't take BCL libraries beyond 8.0.0.0 which is a very different issue.

You could also join the SIG meeting next week to talk to us about it.