Binaries different in different distributions

[iskiselev]

Currently, managed libraries in different distributions (for example OpenTelemetry.AutoInstrumentation) are different over different platforms / distributions.
For example, net/OpenTelemetry.AutoInstrumentation.dll is different in

• linux-arm64
• linux-musl-arm64 / linux-musl-x64
• linux-x64
• windows / nuget

At the same time, netfx/OpenTelemetry.AutoInstrumentation.dll is different in

• windows zip
• nuget packet

Even worse, versions ofnetfx/OpenTelemetry.AutoInstrumentation.dll have different assembly references - for System.Diagnostics.DiagnosticsSource - 9.0.0 for nuget version and 9.0.x for zip version.

Such difference makes much harder tracking OTEL Auto instrumentation in SBOM - and harder to vaildate that file is genue - you need to compare hash with the same distro. It may also result in hard to diagnostics error if user tries to build package on their own.

[nrcventura]

The nuget package operates differently than the other distribution mechanisms. The nuget package is primarily about getting dependencies lined up correctly for individual applications, while the other distribution packages are meant to "install" auto instrumentation onto a system. Because of these functional differences we should consider treating the nuget package separately from the other packages when it comes to validation purposes (the diagnostic source assembly referenced in the nuget package is not guarantied to be the one used by the application).

For the other distribution packages, I'm wondering what the main differences are. For example, I can potentially see some differences in the managed code referencing back into the native code. I don't remember if we need to call out the specific native library name and path to use, which would be different for all of the scenarios described in this issue (the native code is different for each of those environments). Maybe there are some slight differences in the API calls being made on windows and linux, or other libraries that auto instrumentation attempts to bootstrap.

[iskiselev]

Regards nuget / binary distribution. When we compile auto-instrumentation assemblies, we deal with two sets of versions:

• minimum version supported by auto-instrumentation and all dependencies (oldest possible)
• version that we'd like to provide for archive consumers (latest patch)

Currently, build and packaing process are mixed together. It can be seen at OpenTelemetry.AutoInstrumentation.csproj - we check for _IsPacking flag, which result in setting latest patch for System.Diagnostics.DiagnosticSource or not (from Directory.Packages.props) depending on build type.

But we can split it: compile always referencing oldest version, pack archive and create redirections based on selected latest patch. I plan to modify my #4505 to achieve it - as it is already very close, but want to have seperate issue to discuss it and reason why I'll made more changes.

Regards other distribution packages, I have verified ildasm of different distributions of .net versions of OpenTelemetry.AutoInstrumentation.dll - they are all same except MVID (which is expected, as in nuget case all targets use same library from windows version). I beleive that different builds should be just unified by selecting single source on CI build. For managed assemblies any of the build (which produce that assembly with proper TFM) should work - and once assembly reference will be unified, .Net Framework version may be also unified between NuGet and zip.

[nrcventura]

For the nuget package, I believe we just made the smallest change to our existing process in order to start producing a nuget package. If there are benefits to separating some of the steps out then I think that those changes are worth considering.

For the other packages, the main thing we want to be careful of is that we do not place any additional burdens on local development and the ability to run our CI workflows locally. For example, we do not want to require someone to have access to a windows machine if they are using a mac or linux machine in order to fully build the code. Right now the build pipelines for Windows, Linux, and Mac are independent of each other.