Why does System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription report .NET Core 4.0.0.0?

[shanselman]

Why does System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription report .NET Core 4.0.0.0?

/cc @DamianEdwards

[ericstj]

/cc @weshaggard @eerhardt
Original discussion here: dotnet/corefx#5210

[Priya91]

The version returned is "{FrameworkName} {typeof(object).GetTypeInfo().Assembly.GetName().Version}", it's the build version of mscorlib.dll..

Initially we had the frameworkdescription just return the stack used, and then ASP.NET had a request to return some version info. There wasn't clear guidelines on what the version should be, runtime or framework or the version in the brand name. And we decided to go with this.

[akoeplinger]

The discussion in dotnet/corefx#4334 (diff) initially started out with preferring to add the FileVersion, but in dotnet/corefx#5210 (diff) it was replaced by Version because UWP doesn't support the FileVersionInfo stuff.

@Priya91 does reading AssemblyInformationalVersion work on UWP? Here's a simple example app:

using System;
using System.Linq;
using System.Reflection;
using System.Runtime.InteropServices;

namespace ConsoleApplication
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var objectVersion = typeof(object).GetTypeInfo().Assembly.GetCustomAttributes().OfType<AssemblyInformationalVersionAttribute>().Single().InformationalVersion;
            var runtimeinfoVersion = typeof(RuntimeInformation).GetTypeInfo().Assembly.GetCustomAttributes().OfType<AssemblyInformationalVersionAttribute>().Single().InformationalVersion;

            Console.WriteLine("object version: " + objectVersion);
            Console.WriteLine("RuntimeInformation version: " + runtimeinfoVersion);
        }
    }
}

This prints

object version: 4.6.24214.01. Commit Hash: abbb8f685929c7aeaa087dae46fedc1bc2af4b17
RuntimeInformation version: 1.0.24212.01. Commit Hash: 9688ddbb62c04189cac4c4a06e31e93377dccd41

... on my .NET Core 1.0 RTM install, which is like 1000x more useful than 4.0.0.0

[DamianEdwards]

That looks much nicer. Couldn't we make this API implement differently in UWP vs. dotnet.exe host, whether by runtime late-binding or #ifdef, etc.

[ericstj]

because UWP doesn't support the FileVersionInfo stuff.

I added support for that.

[borgdylan]

Small Note: The .NET Core version of S.R.IS.RI gets injected into the compilation even if targeting Mono/.NET due to the netstandard1.1 compatibility. This does not only report ".NETCore,Version=4.0.0.0" as described above but it also produces incorrect output when targeting Mono, since the System.Native.so library has to be provided separately.

[ericstj]

@borgdylan that issue is discussed here: https://github.com/dotnet/corefx/issues/9012.

[borgdylan]

Please, could this API still be able to be included when using full framework and mono. Mono is currently tracking net461 i.e netstandard1.4. I have filed a bug against mono asking for .NET 4.6.2 targeting support which allow the use of netstandard1.5 in the future.

[evil-shrike]

Why the issue is closed? For .NET Core 2.1 RuntimeInformation.FrameworkDescription still reports incorrect version: ".NET Core: 4.6.26515.07"

>dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.300
 Commit:    adab45bf0c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.300\

Host (useful for support):
  Version: 2.1.0
  Commit:  caa7b7e2ba

[danmoseley]

Reopening for discussion if needed.

[jkoritzinsky]

Fixed by dotnet/corefx#35516