You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 30, 2023. It is now read-only.
On non NET Standard 2.0, it'll fallback to: Environment.Version
This is an issue with .NET Framework 4.6+ as it displays the same version for all newer versions (4.6.1, 4.6.2, 4.7, 4.7.1). Microsoft has a guide on finding out the right .NET Framework version installed and since all of these 4.x versions are all in-place installation on CLR 4, the latest version installed is the version we should report, not the version an assembly was targeting when compiled.
Through #237 we've added support to Contexts Interface.
The Runtime information extraction was best effort considering that not even Microsoft has figured out a way to do this properly.
For NET Standard 2.0 we used
RuntimeInformation.FrameworkDescription:CoreCLR 2.0+: The implementation on CoreFX will look into the assembly where
Objectis defined and check the version of that assembly. That makes sense as that type is actually part of the CoreCLR and will have a different version for each runtime.Mono 5.4+: Mono will invoke
Mono.Runtime.GetDisplayName. That, does a platform call to report the version.CLR 4.7.1+: Can't find anything on reference source. Need some investigation to find out how it works here.
On non NET Standard 2.0, it'll fallback to:
Environment.VersionThis is an issue with .NET Framework 4.6+ as it displays the same version for all newer versions (4.6.1, 4.6.2, 4.7, 4.7.1). Microsoft has a guide on finding out the right .NET Framework version installed and since all of these 4.x versions are all in-place installation on CLR 4, the latest version installed is the version we should report, not the version an assembly was targeting when compiled.
BenchmarkDotNet had good progress with this.