Versioning agent assemblies

[russcam]

.NET APM agent packages currently use the same version for AssemblyVersion and AssemblyFileVersion . Take for example Elastic.Apm 1.7.1:

[assembly: AssemblyCompany("Elastic and contributors")]
[assembly: AssemblyConfiguration("Release")]
[assembly: AssemblyCopyright("2020 Elasticsearch BV")]
[assembly: AssemblyDescription("Elastic APM .NET Agent base package. This package provides core functionality for transmitting of all Elastic APM types and is a dependent package for all other Elastic APM package. Additionally this package contains the public Agent API that allows you to manually capture transactions and spans. Please install the platform specific package for the best experience. See: https://github.com/elastic/apm-agent-dotnet/tree/master/docs")]
[assembly: AssemblyFileVersion("1.7.1")]
[assembly: AssemblyInformationalVersion("1.7.1")]
[assembly: AssemblyProduct("Elastic.Apm")]
[assembly: AssemblyTitle("Elastic.Apm")]
[assembly: AssemblyVersion("1.7.1.0")]

The AssemblyVersion is set to 1.7.1.0 and AssemblyFileVersion is set to 1.7.1.

From Microsoft's Open Source library guidance

The assembly version is what the CLR uses at run time to select which version of an assembly to load. Selecting an assembly using versioning only applies to assemblies with a strong name.

The .NET Framework CLR demands an exact match to load a strong-named assembly. For example, Libary1, Version=1.0.0.0 was compiled with a reference to Newtonsoft.Json, Version=11.0.0.0. .NET Framework will only load that exact version 11.0.0.0. To load a different version at run time, a binding redirect must be added to the .NET application's config file.

Strong naming combined with assembly version enables strict assembly version loading. While strong naming a library has a number of benefits, it often results in run-time exceptions that an assembly can't be found and requires binding redirects in app.config or web.config to be fixed. In .NET Core, assembly loading is more relaxed. The .NET Core runtime automatically loads assemblies with a higher version at run time.

Taking NEST as an example, all NEST 7.x nuget packages have AssemblyVersion 7.0.0.0:

[assembly: AssemblyCompany("Elastic and contributors")]
[assembly: AssemblyConfiguration("Release")]
[assembly: AssemblyCopyright("Elasticsearch BV")]
[assembly: AssemblyDescription("\r\n      Strongly typed interface to Elasticsearch. Fluent and classic object initializer mappings of requests and \r\n      responses. Uses and exposes Elasticsearch.Net.\r\n    ")]
[assembly: AssemblyFileVersion("7.10.1.0")]
[assembly: AssemblyInformationalVersion("7.10.1+e607d3126d05ec862c4d2a9de37bfcaecc05a249")]
[assembly: AssemblyProduct("Nest")]
[assembly: AssemblyTitle("Nest")]
[assembly: AssemblyVersion("7.0.0.0")]

What this means is that If all NEST 7.x assemblies are binary compatible (which they're intended to be), a dependent assembly compiled against any NEST 7.x version will be compatible with any other 7.x version. JSON.NET has followed a similar assembly version approach since 4.5.0.

Since the APM agent is also intended to be binary compatible within a major version, we should consider adopting a similar assembly versioning approach