Missing expected assembly when instrumenting .NET Framework apps

[Kielek]

The automatic instrumentation injects, into the application, assemblies from multiple packages from OTel (the SDK, API, exporters, instrumentations, etc). These different packages can depend on different versions of the same assemblies. When the "runtime folders", e.g.: tracer-home\net462, are built the NuGet version resolution will select a single version of any conflicting assembly.

On .NET Framework this behavior becomes a problem because of the strict versioning that it implements on top of strong naming. A concrete example comes from #1647. In this PR the OTLP exporter has a dependency on Google.Protobuf which has a dependency on System.Memory, Version=4.0.1.1. However, other referenced packages depend on System.Memory, Version=4.0.1.2 so after the build only version 4.0.1.2 ends up on tracer-home\net462. At runtime, when automatic instrumentation injects the assemblies, code from Google.Protobuf fails because it tries to load version 4.0.1.1 which is not present.

This is not an issue for manually instrumented applications because when building .NET Framework apps, by default, a binding redirect, mapping all versions to a single one, is added to the application configuration file. However, automatic instrumentation builds as a class library and there are no binding redirects for class libraries.

The way to fix this without requiring the .NET Framework applications to add a reference to the auto-instrumentation NuGet package is to do the "redirect" directly on the assemblies at the Framework "runtime folder". In order to do that it is necessary to update the assembly references in metadata tokens to the single version made available by the NuGet package resolution. This should be done during the build using assembly rewriting packages like Mono.Cecil. The sample listed below shows how the issue on PR #1647 can be fixed with this "redirect".

using Mono.Cecil;

const string targetModuleFile = @"C:\src\otel\dotnet\auto\bin\tracer-home\net462\Google.Protobuf.dll";

using var targetModuleDef = ModuleDefinition.ReadModule(targetModuleFile, new ReaderParameters { ReadWrite = true });
foreach (var assemblyRef in targetModuleDef.AssemblyReferences)
{
    Console.WriteLine(assemblyRef);
}

// Hard-coded the location of the assembly reference that needs to be updated.
targetModuleDef.AssemblyReferences[1].Version = new Version(4, 0, 1, 2);

targetModuleDef.Write();
Console.WriteLine("TargetModuleDef.Write()");

[Kielek]

Remember to remove App.config from TestApplication.Smoke and TestApplication.Http.NetFramework project.

[pjanotti]

Follow-up from the last SIG meeting:

1. The assembly, Google.Protobuf, in which the potential fix above was tested doesn't have an "Authenticode Signature". Hence, validating if the proposed solution works with such assemblies is still necessary.
2. It seems possible to update the AssemblyRef metadata token using the IMetaDataAssemblyEmit::SetAssemblyRefProps Method. This requires inspecting the AssemblyRef tokens when specific modules are loaded. If using build time "redirects" as initially proposed is not viable for some reason we can prototype this alternative.

[pjanotti]

The TestApplication.GraphQL uses some very old packages that are incompatible with the SDK 1.4.0-beta.3: just by adding

 <PackageReference Include="OpenTelemetry" Version="1.4.0-beta.3" />

to the net462 the application breaks at startup with:

Now listening on: http://localhost:5000
Now listening on: https://localhost:5001
Application started. Press Ctrl+C to shut down.
fail: Microsoft.AspNetCore.Server.Kestrel[0]
      Heartbeat.OnHeartbeat
System.TypeLoadException: Could not load type 'Microsoft.Extensions.Primitives.InplaceStringBuilder' from assembly 'Microsoft.Extensions.Primitives, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
   at Microsoft.Net.Http.Headers.DateTimeFormatter.ToRfc1123String(DateTimeOffset dateTime, Boolean quoted)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.DateHeaderValueManager.SetDateValues(DateTimeOffset value)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.DateHeaderValueManager.OnHeartbeat(DateTimeOffset now)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.Heartbeat.OnHeartbeat()

we may have to refactor the test app to not use the unmaintained Microsoft.AspNetCore package.

[pjanotti]

It also seems a good idea to move the transitive dependencies to the highest version supported by our direct dependencies. The reason is that if we use the lower version from our direct dependencies (the default choice for the version range of NuGet packages) we may lower the version being loaded by the application. This can happen if the first reference to the assembly comes from code injected by the instrumentation, in this case, we may end up with a version lower than what the app was built against and cause runtime errors - to be fair there is no guarantee the going to higher version won't cause problems either but the chances are much smaller.

Unfortunately, NuGet doesn't seem to have an easy way to update the transitive dependencies to the latest versions. We probably would have to rely on some tool like dotnet-outdated or implement our own dependency management via a custom build step/target.

[EDIT: tracking this via #1824]

[pjanotti]

Since we are dealing with the potential of using versions that differ from the ones used by the application, see previous comment, we need to have a friendly way to install the assemblies in the netfx to the GAC. Following up via #1823