[HttpClient instrumentation] Runtime failures with a mix of NetFramework and NetStandard

[stephenjust]

Bug Report

List of all OpenTelemetry NuGet
packages and version that you are
using (e.g. OpenTelemetry 1.0.2):
OpenTelemetry.Instrumentation.Http: 1.0.0-rc9.4"

Runtime version (e.g. net462, net48, netcoreapp3.1, net6.0 etc. You can
find this information from the *.csproj file):

"Common component": netstandard2.0
"NetFramework frontent": net472
"NetCore frontend": net5.0

Symptom

My application runs on both Net Framework and Net 5.0 as we are migrating between frameworks.
We have a common netstandard2.0 project shared between the two, to minimize code duplication.

Our OTel tracing setup happens in the common dll that is compiled with netstandard2.0, but when I run the net472 service that incorporates this dll, I get the following exception:

Unhandled Exception: Method not found:
'OpenTelemetry.Trace.TracerProviderBuilder OpenTelemetry.Trace.TracerProviderBuilderExtensions.AddHttpClientInstrumentation(OpenTelemetry.Trace.TracerProviderBuilder, System.Action`1<OpenTelemetry.Instrumentation.Http.HttpClientInstrumentationOptions>)'. at MyServiceNamespace.CommonLib.LoggingSetup.AddCommonInstrumentation(TracerProviderBuilder instance)

My understanding is that this is happening because my common library compiled against the netstandard version of OpenTelemetry.Instrumentation.Http, but at runtime, the .Net Framework version gets packaged with my app, and the .Net Framework version of the library has a slightly different method signature.

What is the expected behavior?

I expect that methods packed into the netstandard2.0 assembly will also be present in netframework and netcore assemblies.

What is the actual behavior?

A method with a different signature is available in the netframework assembly, causing runtime errors.

Reproduce

Fairly self-expalanatory.

Additional Context

The problem originates here. I wonder if the modern path ("else" case) should be present on both runtimes. Alternatively, this nuget should not target netstandard2.0, and instead target net4xx and netstandard2.1, to avoid this unreliable behavior.

[CodeBlanch]

@stephenjust In your shared library couldn't you just target net471;netstandard2.0;net5.0 and essentially forward the correct OTel API where you need it? You'll still achieve a significant amount of sharing.

We have discussed this and maybe we'll split the packages, but that might give you a quick workaround until a solution is available.

[stephenjust]

This is how we worked around the issue, yes. We changed the targets of our shared library to net472;netstandard2.1 to force net framework and core to use different binaries.