Add OSVersion APIs to .NET Core

[Priya91]

The contract System.Runtime.InteropServices.RuntimeInformation provides
RuntimeInformation type that has methods to query for underlying OS
information at runtime. The OS information is expressed by the OSPlatform type.
Reference issue: dotnet\corefx#1017, API Review done on 2015\06\09.

cc @KrzysztofCwalina @weshaggard @terrajobst @nguerrera @justinvp @ellismg @stephentoub

closes issue #1017

[ghost]

Please also add private const string FreeBSDString = "FreeBSD";

CoreCLR is recently configured to build on FreeBSD with CI build setup: https://github.com/dotnet/coreclr/blob/master/README.md#build-status.
Some folks are already working on corefx to build against FreeBSD (search "freebsd" on GitHub in corefx and coreclr repos). With that said, I think FreeBSD deserves some love here. :)

copy @josteink, @saper, @ghuntley, @mmitche

[ghuntley]

See also https://github.com/dotnet/corefx/issues/1576 where naming was discussed within the test suites and #1625 where naming was discussed within the public API.

Important to note that this is the public API contract, if anyone in MSFT wants to choose a different identifier now is the time to speak up. The portteam has pretty much settled on and is happy with using FreeBSD.

private const string FreeBSDString = "FREEBSD"

Additionally you will need to add

public static OSPlatform FreeBSD
{
    get
    {
        return new OSPlatform(FreeBSDString);
    }
}

also /cc: @janhenke

[janhenke]

Yes, we need FreeBSD to be added to the list of OS platforms. As @ghuntley expressed, our preference is using the "FreeBSD" identifier throughout the code.

[ellismg]

(Commenting at the top level instead of on the outdated diff, so the comment is easier to find.)

I do not believe that we should add FreeBSD as a predefined property as part of this PR. As we discussed in the framework design review:

For newer platforms we'd ask the community to first bake their platform (current example would be BSD). We don't have to version the API surface and expose new field from the get go; consumers can always construct the struct with the appropriate value. Once the platform has adoption, we can add an 'official' field that has the appropriate value.

Instead, I would like to see the following happen, after merging the PR as is:

1. The "FreeBSD port team" continues their work to get a FreeBSD version of CoreFX produced (tracked by #1626).
2. The port team brings up enough of the CoreFX and CoreCLR stack on FreeBSD such that we can start running the CoreFX unit tests on FreeBSD.
3. The tests reach some minimal quality level. I don't know exactly what this looks like yet, but I expect it means something like a majority of the tests pass. Ideally we would not have a bunch of specific tests disabled for only FreeBSD (compared to Linux and OSX, we wouldn't want to hold FreeBSD to a higher standard than the other *NIX platforms we have there).
4. Working with the FreeBSD port team, the CoreFX team gets the CoreFX tests added to our CI system running on FreeBSD.
5. Discuss merging a PR based for issue #1625, which adds the property.

I think it's completely reasonable to use #1625 to claim the "FreeBSD" identifier (I would suggest that we use "FREEBSD" since we put the other monikers in all caps). Folks that want to do platform detection can use OSPlatfom.Create("FREEBSD") and I'd be happy if part of bringing up the stack includes the work to produce a version of System.Runtime.Environment for FreeBSD that returns true for an OSPlatform name of "FREEBSD". But I don't think we should feel like we need to add the property right away. The design we have was built in order to be able to decouple adding property to the surface area from having an implementation be able to return true for it.

/cc @stephentoub @richlander. What do the two of you think about this approach?

[stephentoub]

Thanks, @ellismg. Well stated, and I fully agree. As part of (2), as you suggest, one of the first libraries implemented on FreeBSD could be this one, to recognize "FREEBSD" as the OS name string, but as you've stated that doesn't require any new public surface area.

[mmitche]

@ellismg That seems like a good approach to me

[richlander]

I also think that this is a good plan.

The initial plan with the port team around CI was similar to this. It isn't about setting arbitrary goals for the port team (in a schedule/milestone sense), but a statement to the community on where a given port is at. We want to make sure that people have a good experience with a port and any sort of official statements from the MS team will lead people to believe that they will.

Certainly, we could add this property w/o harm. It's about being consistent.

Fair?

@janhenke, @ghuntley, @josteink

[josteink]

I'm OK with the approach outlined by @ellismg. As long as we have a clean way to do platform-detection "in the meantime", I don't see the need to commit anyone to a permanent API. And like @richlander says, we then avoid having MS send messages about readiness until we're comfortable doing so.

[Priya91]

@KrzysztofCwalina : Can you please review this.. Thanks!

[josteink]

Any progress on getting this issue merged?

The FreeBSD port team is eager to add System.Runtime-implementations, but cannot until this one is resolved and merged due to the structural changes it introduces.

[KrzysztofCwalina]

looks good.

[akoeplinger]

@Priya91 sorry for not catching this earlier, but the parameter name for the exceptions is wrong here: name osPlatform

[ghuntley]

Fixed by commit 2f31aa9