Improve .NET Core version APIs #28701
Description
There should be APIs to get the actual .NET Version and the commit SHA for .NET Core. The version APIs have been a weak point of the product since .NET Core 1.0. If we're going to change existing behavior a major version would be a good time!
In particular, Environment.Version and RuntimeInformation.FrameworkDescription seem nearly useless in the majority of cases. It is particularly cute that they return different values. At least they agree on 4.x!
The OS Version and Bitness APIs are included for completeness. The OS version APIs could likely be improved in some way, but I don't have a specific need for that.
This is what I can produce today:
C:\testapps\versioninfo>dotnet run
.NET Core version:
Environment.Version: 4.0.30319.42000
RuntimeInformation.FrameworkDescription: .NET Core 4.6.27322.0
RichHack.Version: 3.0.0-preview-27324-5
RichHack.CommitUrl: https://github.com/dotnet/coreclr/tree/b9e88989458e24fa9764e045917b141e3338eae7
OS Version
Environment.OSVersion: Microsoft Windows NT 6.2.9200.0
RuntimeInformation.OSDescription: Microsoft Windows 10.0.17763
Bitness
RuntimeInformation.OSArchitecture: X64
RuntimeInformation.ProcessArchitecture: X64
Environment.Is64BitOperatingSystem: True
Environment.Is64BitProcess: True
C:\testapps\versioninfo>docker run --rm -it -v C:\testapps\versioninfo:/app -w /app microsoft/dotnet:3.0-sdk-alpine dotnet run
.NET Core version:
Environment.Version: 4.0.30319.42000
RuntimeInformation.FrameworkDescription: .NET Core 4.6.27322.0
RichHack.Version: 3.0.0-preview-27324-5
RichHack.CommitUrl: https://github.com/dotnet/coreclr/tree/b9e88989458e24fa9764e045917b141e3338eae7
OS Version
Environment.OSVersion: Unix 4.9.125.0
RuntimeInformation.OSDescription: Linux 4.9.125-linuxkit dotnet/corefx#1 SMP Fri Sep 7 08:20:28 UTC 2018
Bitness
RuntimeInformation.OSArchitecture: X64
RuntimeInformation.ProcessArchitecture: X64
Environment.Is64BitOperatingSystem: True
Environment.Is64BitProcess: TrueI updated the code, and made it more focused on the key scenario and switched to approved patterns (modulo the fact that my code will crash if the AssemblyInformationalVersionAttribute string is not maintained):
Existing behavior:
C:\testapps\versioninfo>dotnet run
.NET Core version:
Environment.Version: 4.0.30319.42000
RuntimeInformation.FrameworkDescription: .NET Core 4.6.27415.71
CoreFX Build: 4.7.0-preview4.19113.15
CoreFX Hash: add4cacbfb7f7d3f5f07630d10b24e38da4ad027Code: https://gist.github.com/richlander/f5849c6967c66d699301f75101906f99
Desired behavior for a preview:
C:\testapps\versioninfo>dotnet run
.NET Core version:
Environment.Version: 3.0.0
RuntimeInformation.FrameworkDescription: .NET Core 3.0.0-preview4.19113.15
CoreFX Build: 3.0.0-preview4.19113.15
CoreFX Hash: add4cacbfb7f7d3f5f07630d10b24e38da4ad027Desired behavior for a release build:
C:\testapps\versioninfo>dotnet run
.NET Core version:
Environment.Version: 3.0.2
RuntimeInformation.FrameworkDescription: .NET Core 3.0.2
CoreFX Build: 3.0.2
CoreFX Hash: dda4cacbfb7f7d3f5f07630d10b24e38da4ad027Note: I have documented this with CoreFX since it has implemented the new format for AssemblyInformationalVersionAttribute. CoreCLR has not done that yet, but will. If both were in place, I'd include both in my sample.
Note: There is no way to get this information for the actual CoreCLR runtime. The build and hash values for System.Private.CoreLib.dll and CoreCLR are expected to be uniform 99% of the time.