Proposed additions to RuntimeInformation

[leecow]

https://github.com/dotnet/corefx/issues/12737

RuntimeInformation

Rational and Usage

It is often desirable and necessary for applications to determine execution environment and runtime information. Existing information provided by System.Runtime.InteropServices.RuntimeInformation could be enhanced and expanded with additional API to provide robust information.

System.Runtime.InteropServices.RuntimeInformation currently provides surface for some of information though modification to current behavior or addition API may be needed.

Existing API

• OSPlatform
• ProcessAchitecture
• OSArchitecture
• OSDescription
• FrameworkDescription
• IsOSPlatform

Proposed additions

• OSName - Windows, Mac, Ubuntu, Red Hat Enterprise Linux Server
• OSVersion - following the previous examples - 10.0.15027, 10.12.3, 16.10, 7.2
• RuntimeVersions - Runtime version currently used by the application, eg NETCore.App 1.0.4
• InstalledRuntimeVersions - List of targetable runtime on system

Open Questions

Updates

Appendix

/etc/os-release will have the pertinent information on all systemd-based distros. All distros in our current support set use systemd. Alpine Linux includes /etc/os-release.
Variables can be accessed directly with ( source /etc/os-release && echo "$PRETTY_NAME" )

Fedora:

	NAME=Fedora
	VERSION="24 (Workstation Edition)"
	ID=fedora
	VERSION_ID=24
	PRETTY_NAME="Fedora 24 (Workstation Edition)"
	ANSI_COLOR="0;34"
	CPE_NAME="cpe:/o:fedoraproject:fedora:24"
	HOME_URL="https://fedoraproject.org/"
	BUG_REPORT_URL="https://bugzilla.redhat.com/"
	REDHAT_BUGZILLA_PRODUCT="Fedora"
	REDHAT_BUGZILLA_PRODUCT_VERSION=24
	REDHAT_SUPPORT_PRODUCT="Fedora"
	REDHAT_SUPPORT_PRODUCT_VERSION=24
	PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
	VARIANT="Workstation Edition"
	VARIANT_ID=workstation

Alpine:

	NAME="Alpine Linux"
	ID=alpine
	VERSION_ID=3.5.0
	PRETTY_NAME="Alpine Linux v3.5"
	HOME_URL="http://alpinelinux.org"
	BUG_REPORT_URL="http://bugs.alpinelinux.org"

/cc @richlander , @mellinoe , @Petermarcu , @AlexGhiondea , @weshaggard , @danmosemsft

[danmoseley]

I was literally this morning typing up a proposal to at least add a strongly typed enum for runtime name.

Right now to figure out we are running on desktop, we do string parsing:
if (RuntimeInformation.FrameworkDescription.StartsWith(".NET Framework"))

it should be possible to do something like
if (RuntimeInformation.Framework.IsDesktopFramework) or if (RuntimeInformation.FrameworkIs(Frameworks.Desktop))

[weshaggard]

For the Version APIs how do you propose we determine each of them?

For example for OSVersion not all OS's are pure number based versions, so should this be a string or a new Version type that supports semantic versioning?

For the RuntimeVersion where would we embed this information? Today we don't really have a way to determine what .NET Core you are running on. When running on the shared framework we might be able to figure some of that out but when not I'm not sure where that would come from.

Similar for InstalledRuntimeVersions where would we probe for that information?

Right now to figure out we are running on desktop, we do string parsing:
if (RuntimeInformation.FrameworkDescription.StartsWith(".NET Framework"))

@danmosemsft FrameworkDescription is intended for logging information. To determine which framework people built against for runtime checks you should be using AppContext.TargetFramework.

[leecow]

I wouldn't think we would invent anything clever for OSVersion. Return what is readily offered by the system. In the Linux case it happens to look like a number.

Could we rely on the contents of /share/Microsoft.NETCore.App or is that too naive?

[weshaggard]

I wouldn't think we would invent anything clever for OSVersion. Return what is readily offered by the system. In the Linux case it happens to look like a number.

It can contain more then just numeric versions see https://www.freedesktop.org/software/systemd/man/os-release.html

Could we rely on the contents of /share/Microsoft.NETCore.App or is that too naive?

That might help for shared applications but doesn't help for standalone at all.

[leecow]

It can contain more then just numeric versions

Yes, I understand that. Just suggesting we return whatever is readily available, eg a string.

It can contain more then just numeric versions

That's why the smart folks are here to figure out the options ;-)

[weshaggard]

Yes, I understand that. Just suggesting we return whatever is readily available, eg a string.

Can I ask you to update the proposal with some scenarios (i.e. coding scenarios) we want folks to be doing with these new APIs? If we plan folks to make runtime decisions based on this version then having it be a string isn't a good way to expose this information because everyone will still have to figure out how to parse it.

That's why the smart folks are here to figure out the options ;-)

There isn't any good way that I'm aware of to do this, that would work across all our .NET Platforms, which is why I'm asking questions.

[MichalStrehovsky]

For the OSVersion thing, it might not be possible to reliably implement this on Windows (e.g. GetVersionEx will return the version that the program is manifested for and never anything higher - and Windows team is slowly eradicating other undocumented places people use to get Windows version). They really don't want programs to use that to drive decisions.

[mellinoe]

And how about the supported in other platforms, like Android, iOS, FreeBSD, etc.? Do we have an idea about what facilities exist there?

[Priya91]

If the intention to use os version is to make runtime decisions for the availability of a feature, etc, then we could have an api like CheckFeaturePresent, that could be a wrapper on pinvoke to check the existence of the native library. The point being to understand why os version is required for runtime decisions and find a different way to get that data without having to depend on correctly identifying the os version.

For other purposes like displaying the version, we can just return a string that we get from the OS. How the developer intends to use this string, will be out of scope of the .NET API contract. This API will be similar to os.name, os.version system properties on Java, and runtime.GOOS env variables on Go.

[leecow]

Priya is capturing the primary use category I was envisioning. Namely, this will simply report environment information as presented by the OS and attempting to account for the usage of the data is essentially impossible.

Will add a few scenarios including those which have been raised in other issues to hopefully clarify.

[eerhardt]

Note we already have OperatingSystem and OperatingSystemVersion in PlatformAbstractions:

https://github.com/dotnet/core-setup/blob/master/src/managed/Microsoft.DotNet.PlatformAbstractions/RuntimeEnvironment.cs#L15-L17

These values are necessary to figure out the RID of the machine.

Can consumers who need these values just use these existing APIs?

[eerhardt]

@weshaggard @terrajobst - we really should rectify the APIs in PlatformAbstractions with RuntimeInformation.

The APIs in PlatformAbstractions came from needing this functionality in the CLI, but not having the necessary APIs in the BCL. So the CLI team created these APIs and they made their way into dotnet/core-setup. We (the runtime team) own both corefx and core-setup and the APIs exposed by both repos. So we should have a coherent story here.

[tmat]

Any managed library (such as msbuild task) that loads native library needs to know RID. This need came up recently in libgit2sharp. We should add GetRuntimeId method.

Since dotnet/corefx#16629, dotnet/corefx#17452, dotnet/corefx#23197, dotnet/corefx#24522, dotnet/corefx#25530, dotnet/corefx#27417 and dotnet/corefx#28132 are all similar proposals if we think from the perspective of bringing over https://github.com/dotnet/core-setup/tree/fd1dc48fad5bc32258c8c0fc885fbf4b1e32bebd/src/managed/Microsoft.DotNet.PlatformAbstractions to CoreFX that was proposed in https://github.com/dotnet/corefx/issues/28620 by @weshaggard, could the area owner of S.R.I.RuntimeInformation combine these proposals for a more broader API review encompassing various known use-cases?