RuntimeEnvironment.GetSystemVersion returns wrong version

[luchunminglu]

Description

I write code in dotnet7, but RuntimeEnvironment.GetSystemVersion() returns v4.0.30319

Reproduction Steps

public static void Main(string[] args)
{
Console.WriteLine(RuntimeEnvironment.GetSystemVersion());
}

Expected behavior

7.0.7

Actual behavior

v4.0.30319

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I write code in dotnet7, but RuntimeEnvironment.GetSystemVersion() returns v4.0.30319

Reproduction Steps

public static void Main(string[] args)
{
Console.WriteLine(RuntimeEnvironment.GetSystemVersion());
}

Expected behavior

7.0.7

Actual behavior

v4.0.30319

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	luchunminglu
Assignees:	-
Labels:	area-System.Runtime.InteropServices, untriaged, needs-area-label
Milestone:	-

[huoyaoyuan]

RuntimeEnvironment.GetSystemVersion() returns the "runtime version" attribute of corelib image:

runtime/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RuntimeEnvironment.cs

Line 37 in 2e764d6

public static string GetSystemVersion() => typeof(object).Assembly.ImageRuntimeVersion;

The "runtime version" is actually an indicator of .NET Framework in-place replacement, not product releases. For example, for .NET Framework 2.0-3.5 it's v2.0.50727, and for 4.X it's always v4.0.30319.

You can use RuntimeInformation.FrameworkDescription to get a better version string. Environment.Version also returns the version in expected value now.

We should probably obsolete the entire RuntimeEnvironment type since it's not providing meaningful information in .NET core.

[svick]

@huoyaoyuan I think the documentation should also be updated. Currently, it says:

Gets the version number of the common language runtime that is running the current process.

Which doesn't really tell you anything.

[joshudson]

I would argue that for most processes, null is the correct return, because for .NET Core processes, the framework CLR is not loaded (check DLL list). If you load the framework CLR via a P/Invoke to a mixed-mode DLL, expect something wild to happen.

[AaronRobinsonMSFT]

@richlander I recall you working on the version confusion in a previous release. Do you have any insight into this API and how you would expect it documented? The current implementation is below.

runtime/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RuntimeEnvironment.cs

Line 37 in 84873e6

public static string GetSystemVersion() => typeof(object).Assembly.ImageRuntimeVersion;

[jkotas]

I think we should make this API to return meaningful version, ie return v8.0.0 in .NET 8.

[AaronRobinsonMSFT]

Will do. If we start returning v8.0.0, does that mean we need to update the doc in any meaningful way?

[stephentoub]

I agree with Jan. Unless we discover something that doing so would massively break, it'd be good to have this return something "correct" for the .NET being used.

[stephentoub]

Will do. If we start returning v8.0.0, does that mean we need to update the doc in any meaningful way?

We could simplify the docs https://learn.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.runtimeenvironment.getsystemversion from "common language runtime" to just "runtime" to just be a bit more general, but I don't know that it matters.

public static string GetSystemVersion() => typeof(object).Assembly.ImageRuntimeVersion;

Presumably we could just change the implementation to be something like:

public static string GetSystemVersion() => RuntimeInformation.FrameworkDescription;

?

[AaronRobinsonMSFT]

Presumably we could just change the implementation to be something like:

Yep, that is what I am checking now to confirm it does what we want.

[AaronRobinsonMSFT]

I'm following the work/goals done in #28788, fair?