At our organisation running a large fleet of .NET services, a deceptively simple question can be surprisingly hard to answer: what versions of .NET are our apps actually running in production?
You'd think this would be easy. It isn't. Services get deployed, teams move on, and before long nobody is quite sure whether that one legacy service is still on .NET 6 — or even .NET Core 3.1. Spreadsheets fall out of date. README files lie. The only source of truth is what's actually running.
We solved this with three lines of OpenTelemetry configuration.
The problem
We run dozens of .NET services across multiple teams. We are the middle of a push to .NET 10, but we have no reliable, centralised way to see the current state. We wanted to answer questions like:
- Which services are still on end-of-life .NET versions?
- Which teams still have work to do?
- After a migration wave, how do we confirm everything moved?
The solution
We already had OpenTelemetry set up across all our services, shipping telemetry to Azure Monitor(Application Insights). The key insight was that OpenTelemetry's Resource concept is designed exactly for this kind of thing — it's where you attach metadata that describes what is producing the telemetry, not just what the telemetry says.
We added this to each service's startup code:
That's it. Environment.Version gives you the exact CLR version at runtime — no guessing, no config files, no manual input. It goes straight into the resource attributes on every piece of telemetry that service emits.
Why resource attributes?
You might wonder: why not just log it? Logs get noisy, they require you to remember to emit them, and they're harder to aggregate. Resource attributes, by contrast, are attached to all telemetry from a service — traces, metrics, logs — automatically and consistently. They're designed for exactly this kind of "what is this service?" metadata.
Once the attribute is in Azure Monitor, querying it is straightforward. In Log Analytics you can write a KQL query across your AppDependencies, AppRequests, or AppTraces tables and group by customDimensions["runtime.dotnet.version"] to get a live view of your runtime landscape.
The broader pattern
This is a small example of a broader principle: your observability infrastructure is also your platform visibility infrastructure. OpenTelemetry resource attributes are a low-friction place to attach facts about your services that you want to be able to query and aggregate centrally — runtime version, deployment region, team ownership, feature flags, whatever matters to your org.
The three lines of code above cost almost nothing to add. The visibility they provide is genuinely useful.
More information
.NET Observability with OpenTelemetry - .NET | Microsoft Learn