We recently hit a surprising bit of behaviour by MSBuild related to this project. It turns out that the order of framework precedence means that any NET Framework compile ends up pulling the net45 target, despite netstandard2.0 being later, offering more features, less bugs, etc.
In particular this means any net45 specific behaviour that turns out to be a problem simply due to age of the associated language feature, e.g. AsyncLocalManager's remoting, is very hard to avoid.
It would be ideal if the preprocessor usage in the tracer assembly used the NET Standard 2.0 approach (wherever that is necessary) also for a later netxxx target (which will avoid surprises like this).
In theory net461 matches netstandard2.0 in API surface area, but given the Microsoft fine print:
there are several issues with consuming .NET Standard libraries that were built for those versions from .NET Framework 4.6.1 projects. For .NET Framework projects that need to use such libraries, we recommend that you upgrade the project to target .NET Framework 4.7.2 or higher.
I will add this if there's going to be a new release - see #128. There's not much going on here anymore as most work is done in the newer OpenTelemetry project.
We recently hit a surprising bit of behaviour by MSBuild related to this project. It turns out that the order of framework precedence means that any NET Framework compile ends up pulling the
net45
target, despitenetstandard2.0
being later, offering more features, less bugs, etc.In particular this means any
net45
specific behaviour that turns out to be a problem simply due to age of the associated language feature, e.g. AsyncLocalManager's remoting, is very hard to avoid.It would be ideal if the preprocessor usage in the tracer assembly used the NET Standard 2.0 approach (wherever that is necessary) also for a later
netxxx
target (which will avoid surprises like this).In theory
net461
matchesnetstandard2.0
in API surface area, but given the Microsoft fine print:This could just be
net472
for safety's sake.