OpenTelemetry support for .NET 10: A behind-the-scenes look

At Grafana Labs, we are fully committed to the open source OpenTelemetry project and are actively engaged with the OTel community. Many Grafanistas spend a large proportion of their time contributing directly to OpenTelemetry upstream projects, helping make observability more powerful, reliable, and accessible for everyone as part of our big tent philosophy.

We specifically contribute to many of the OpenTelemetry SDKs, including those for Java, JavaScript, and .NET, that developers use to enrich their applications with deep insights. In my role as a software engineer here at Grafana Labs, I focus on the OpenTelemetry .NET SDK.

In June 2025, we started to work with the upstream OpenTelemetry .NET instrumentation repositories to validate and deliver native support for .NET 10, the most productive and performant version of .NET yet. And in November 2025, we were able to deliver native OpenTelemetry support for .NET 10, which was an exciting milestone for my team and the OTel community at large.

In this post, I’ll offer a behind-the-scenes look at this journey, and share a few updates about how we’re helping those who use OpenTelemetry signals within their .NET applications move to .NET 10.

An overview of .NET release cycles

Since the release of .NET 5 in 2020, Microsoft has released a new major version of .NET every November. These alternate between an odd-numbered Short Term Support (STS) release that has two years of support, and an even-numbered Long Term Support (LTS) release that is supported for three years.

Below is a graphic from the .NET site that illustrates how this works in practice:

This means .NET 10 is now the latest release of .NET, superseding both .NET 8 as LTS and .NET 9 as the latest version for those running the modern cross-platform variant of .NET. 

The benefits of .NET preview validation

The .NET team provides preview builds of the next major version of .NET, which are available for testing and validation months before the final stable version is scheduled to be released. Testing existing code bases with these candidates allows the wider .NET community to provide valuable feedback to the .NET engineering teams on new features, as well as report regressions that might have occurred during the process.

A .NET upgrade often provides performance improvements in your applications. For example, just by upgrading your .NET SDK and your Target Framework Moniker (TFM) to the latest version, you can benefit from the performance improvements that have been made in the runtime and libraries since the previous release. You don’t need to implement new features or APIs to get the performance improvements; you can just leave your code as it is.

For teams trying to take advantage of these ongoing improvements, the last thing they want is to have an upgrade blocked by a third-party dependency that introduces an incompatibility. This is what motivated us to start validating the .NET OpenTelemetry libraries with .NET 10 early in the release cycle. We wanted to ensure any blockers that may have been discovered were resolved in plenty of time.

For example, one benefit of this prerelease testing was an issue we identified in the .NET logging source generator that affected projects targeting .NET Framework using the .NET 10 SDK. By identifying the issue while .NET 10 was still in preview, we were able to resolve the regression in time for Release Candidate 2 ahead of the stable release.

OpenTelemetry support for .NET 10 

Thanks to this extended testing period, the OpenTelemetry instrumentation libraries were able to deliver native support for .NET 10, and leverage new features, the same week as .NET 10’s first stable release in November 2025. The majority of the required changes were prepared and validated in advance of the release date.

This allowed us to stabilize OpenTelemetry auto-instrumentation (zero code) support for .NET 10 shortly after, as well as publish a new version of the Grafana OpenTelemetry distribution for .NET with support for .NET 10.

Benefits from this new release of .NET include:

• Support for schema URLs for metrics and traces
• Aligning dependencies’ versions with the major .NET version
• New ASP.NET Core metrics for:
  • Authentication/authorization
  • Blazor
  • The memory pool

These changes also lay the groundwork for future improvements to add support for schema URLs to the OpenTelemetry console and OLTP exporters, and for resource attributes.

There is a breaking behavior change to be aware of for telemetry, where the default trace context propagator has been switched from the legacy propagator to the W3C propagator.

Another thing to watch for when using .NET 10 assemblies in.NET Framework applications is binding redirects, especially where you’ve applied them to a range such as 0.0.0.0-9.9.9.9 to avoid making regular changes to your application configuration files. As 10 is greater than 9, make sure to update them so they work for .NET 10 and beyond (maybe 99 is forward-thinking enough...?).

Wrapping up

.NET 10 introduced new levels of performance and productivity and OpenTelemetry libraries for .NET are right there alongside it, helping developers gain the deep insights they need to monitor and debug their applications.

Whether you’re using the Grafana LGTM stack (Loki for logs, Grafana for visualization, Tempo for traces, and Mimir for metrics), or another observability solution, we hope the latest version of the OpenTelemetry .NET SDK helps you unlock more value from your .NET applications. And we’re looking forward to whatever improvements OpenTelemetry and the next major version of .NET bring to observability this year.