Opentelemetry-dotnet: Support for .NET 4.5.2

[reyang]

.NET 4.5.2 is still supported by .NET and will be supported until 10/10/2023.
I wonder if we need to support it in OpenTelemetry .NET SDK.

The life cycle of .NET 4.5.2 is tight to Windows Server 2012 R2 https://docs.microsoft.com/en-us/lifecycle/faq/dotnet-framework:

• Support for .NET 4.5.2 follows the lifecycle policy of the parent OS. It is supported as a Windows component on the latest required operating system update for Windows Vista SP2, Windows 7 SP1, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows 8.1 Update, Windows Server 2012, and Windows Server 2012 R2.

Windows Server 2012 R2 extended end of life will happen on 10/10/2023.

Related to #435.

[eddynaka]

I started to add supportability to some of the Exporters. OpenTelemetry.Exporter.Console depends on System.Text.Json, but that doesn't work for .NET 4.5.2. Should I use Newtonsoft instead? If Yes, which version should I add?

[cijothomas]

I started to add supportability to some of the Exporters. OpenTelemetry.Exporter.Console depends on System.Text.Json, but that doesn't work for .NET 4.5.2. Should I use Newtonsoft instead? If Yes, which version should I add?
ConsoleExporter is just for local testing, and not official OT exporter. its fine to leave it without 452

[eddynaka]

hi @cijothomas , thanks for the answer.

Next question: .net 452 DateTimeOffset doesn't have ToUnixTimeMilliseconds. What would be a good replace for that?

[eddynaka]

looking at reference source we can see the function logic:

private const int DaysPerYear = 365;
private const int DaysPer4Years = DaysPerYear * 4 + 1;       // 1461
private const int DaysPer100Years = DaysPer4Years * 25 - 1;  // 36524
private const int DaysPer400Years = DaysPer100Years * 4 + 1; // 146097
private const int DaysTo1970 = DaysPer400Years * 4 + DaysPer100Years * 3 + DaysPer4Years * 17 + DaysPerYear; // 719,162
private const long UnixEpochTicks = TimeSpan.TicksPerDay * DaysTo1970; // 621,355,968,000,000,000
private const long UnixEpochMilliseconds = UnixEpochTicks / TimeSpan.TicksPerMillisecond; // 62,135,596,800,000

public static long ToUnixTimeMilliseconds()
{
    // Truncate sub-millisecond precision before offsetting by the Unix Epoch to avoid
    // the last digit being off by one for dates that result in negative Unix times
    long milliseconds = DateTime.UtcNow.Ticks / TimeSpan.TicksPerMillisecond;
    return milliseconds - UnixEpochMilliseconds;
}

Should I add this function somewhere?

[reyang]

One possible way - make an extension method ToUnixTimeMilliseconds and guard it using NET452, scope it so it is only visible to this project.

[eddynaka]

@reyang , where do you suggest to create that?

[reyang]

@reyang , where do you suggest to create that?

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods

[eddynaka]

From what i can see, we still have this projects:

• OpenTelemetry.Api: this targets net45, should i change to 452 or add 452?
• OpenTelemetry.Exporter.Jaeger: we have some methods that doesn't exist in 452, for example, TryGetBuffer. Should i migrate this or should leave this way?
• OpenTelemetry.Exporter.Zipkin: i saw the use of Utf8JsonWriter from System.Text.Json, but, if we target 452, we would have to use newtonsoft (as i saw in other projects), but i couldn't find a way to do the same thing. Do you have any suggestion?

[cijothomas]

For API - i think we can change to net452. There should be no need to support net45 as net45 is no officially supported framework anymore.

@reyang do we have to make Zipkin/Jaeger work for net452 ? Or we can leave them as not supported for net452?

[eddynaka]

@cijothomas , ok, i will open a new pr just updating net452 to api project. for jaeger, the main problem is the task.cancellation. for the other parts, i found a workaround.

[reyang]

@eddynaka @cijothomas regarding Newtonsoft.JSON for 4.5.2, alternative way is JavaScriptSerializer.

[reyang]

For API - i think we can change to net452. There should be no need to support net45 as net45 is no officially supported framework anymore.

@reyang do we have to make Zipkin/Jaeger work for net452 ? Or we can leave them as not supported for net452?

I don't see an immediate need for now. I think net452 should cover API, SDK and integration with .NET (e.g. ASP.NET). Other parts are nice to have but not required.

[reyang]

• OpenTelemetry.Api: this targets net45, should i change to 452 or add 452?

Given 4.5 and 4.5.1 were deprecated since 2016-01-12, I think it won't make much sense to support them.

[eddynaka]

Hi all,

just to update:

• OT.Exporter.Zipkin: PR opened
• OT.Exporter.Jaeger: having some problems with Task.FromCanceled that isn't available in net452. Still didn't find an answer for that.
• OT.Api: PR merged
• OT.Instrumentation.StackExchangeRedis: we have a dependency that we can't use for net452.

[eddynaka]

@reyang , just to let you know, we ported almost all to 452, except the list below:

• OT.Exporter.Jaeger: ported to .NET 4.6
• OT.Instrumentation.StackExchangeRedis: already ported to .NET461 (because we have a nuget dependency)

Maybe we can close this. What do you think?

[reyang]

Maybe we can close this. What do you think?

Roger that, thanks @eddynaka!