[Breaking Change] Improving .NET Core Version APIs

We are improving the .NET Core version APIs in .NET Core 3.0. The particular changes we made are technically breaking. The changes are currently only in the master branch, so will be part of .NET Core 3.0 Preview 4, modulo feedback.

Also posted at dotnet/corefx #35573

Related:

• Improve .NET Core version APIs dotnet/corefx #35361
• Make Environment.Version return the actual runtime version dotnet/corefx #31099
• Use product version in RuntimeInformation.FrameworkDescription dotnet/corefx #35516
• Change Environment.Version to return product version dotnet/coreclr dotnet/coreclr#22664

Goal

The goal of the improvement is to enable access to accurate and precise product version information, like is displayed in the following example:

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: add4cacbfb7f7d3f5f07630d10b24e38da4ad027

Code: https://gist.github.com/richlander/f5849c6967c66d699301f75101906f99

Existing Behavior

The product (as of .NET Core 3.0 Preview 3) does not provide the version information displayed above, but seemingly arbitrary values, as displayed in the following example (using the same code):

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: add4cacbfb7f7d3f5f07630d10b24e38da4ad027

Note: These version strings are based on the .NET Framework heritage of the product.

Breaking Change

The change is technically breaking because it resets the versioning scheme of the product as reported by these APIs. Some code somewhere will break, however, we do not expect that to be pervasive. Unfortunately, it will be hard to write code that works with both the new behavior and old behavior given how close the values are.

We should never have shipped .NET Core 1.0 with this behavior to avoid this problem now. We decided that .NET Core 3.0 is likely our last chance to fix these APIs, so decided to take the opportunity now.

Feedback

We would love your feedback.