Support for .NET Framework 3.5

[davidwallis]

Hi,

I was just trying out the .net auto instrumentation as I have some old code which doesn't support otel without major effort on our side. (classic asp.net and framework 3.5)

I'm just wondering if there is anyway to have the auto instrumentation to inject the trace id as a server variable or header so that the legacy code can access it without having to re-write an old monolith (which is happening anyway but need a short term fix)

[Kielek]

Hi @davidwallis,

Please check https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/tree/v1.9.0?tab=readme-ov-file#compatibility

For 1.9.0 version there is a support for .NET Framework 4.6.2+ and .NET6, 7 and 8.
I expect shortly new release with support for the NET Framework 4.6.2+ and .NET8, and 9.

.NET Framework 3.5 was never supported by the OpenTelemetry SDK/AutoInstrumentation.

Do you see any option to upgrade your product to .NET Fx 4.6.2? It will be not for free, but it can be one of the steps to consider if you need telemetry.

The other option is to probably use some proprietary instrumentation code. Usually, not relaying on OpenTelemetry. There should be couple vendors still supporting .NET Framework 3.5.

[davidwallis]

As I said the re-write to newer tech is already happening, was just wondering if there was any options for exposing the auto instrumentation for IIS - which appears to assign a traceid for a request- unless I'm missing something, so was just wondering if there was anyway I could grab that (via a header or similar) to then instrument manually.

[RassK]

@davidwallis propagation adds trace context to the request headers (or other metadata if non http request). You can grab or inject ids to bridge trace context propagation, but there is nothing that's going to export the specific spans (from old systems) to an ingest, as each app is responsible doing itself.

I guess it's easier to update than creating a mini OTel SDK for 3.5.

[davidwallis]

I thought I'd just post back an update on this..

I tried a couple of methods - one creating a com visible library in .net (c#) that would effectively proxy the methods we needed that we should have been able to reference from the old .net 3.51 code, this was flawed as microsoft dont like .net to call a .net dll via com and tell you to go away and add an assembly ref and you are back at square one.

So what I ended up doing as a POC is creating a Visual C++ 2022 solution using the ATL framework for creating com apps.

I then added the C++ version of opentelemetry to this project and then exposed some methods to start, stop activities and add tags..

This can then be called via COM from our legacy code (some vb6 in places, .net 3.51, powershell, hell even vbscript!)

This is crude but its faster than waiting on tech modernisation, and even feasable for some old products that are sunset and aren't receiving any active development)

I'm unable to share the code here at the moment due to Contractual reasons, but I will probably take the time to write an equivalent version and share an example in my own time sometime soon if there is any interest.