[RFC] Detecting current OS

[radical]

MSBuild sets the $(OS) property to OSX/Unix/Windows at runtime, which can be used in targets to determine the current OS. But xbuild has been using $(OS)==Unix on OSX and Linux, because of an old mono bug. And it continues to do so for compatibility reasons.

It makes sense for MSBuild to follow the same, since users would want to use it with existing targets. PR #538 reverts back to that behavior. So, for non-windows case, $(OS) property is effectively acting as a IsUnixLike. Considering it like that, $(OS) should probably have only two values now - Windows_NT and Unix.

Now, I think it might be useful to be able to differentiate between OSX and other specific unices. But maybe we should use some other (new) property for that? $(OSName) ? I am not sure how the CoreCLR case is affected by this, but AFAIU, it would be in the same boat.

Thoughts?

[akoeplinger]

We just discussed this in Xamarin and we came to the conclusion that MSBuild changing $(OS) to OSX is too much of a breaking change for us, so when we adopt MSBuild we need to quirk this to return Unix again to prevent breaking existing code. This has the unfortunate side effect of creating a behavior difference based on the runtime.

@rainersigwald you said in #446 (comment) that you think it's reasonable to update conditions when moving to MSBuild, but is there a chance we can revisit this decision?

[jonpryor]

For bad added context, there are 140 matches on github for .targets files which contain both OS and Unix (my possibly futile effort at capturing constructs similar to Condition="'$(OS)' == 'Unix'").

There are 1,653 matches when targeting .csproj files.

This isn't necessarily "a lot" -- or even accurate? -- but it does show that plenty of existing code files use $(OS) in one form or another, and adding a new value has the potential to break all of these existing files.

Changing $(OS) to be OSX instead of Unix is at minimum a possible compatibility break, and I believe shows that the "abstraction" isn't abstract enough. Users would likely be better served with an alternate mechanism that was more conducive to supporting new platforms without requiring auditing all existing use of e.g. $(OS), though I'm not sure what such an abstraction would resemble.

[AndyGerlicher]

We discussed this a bit today in our team meeting. This is a tricky one because msbuild isn't exactly the same as xbuild. So if we're migrating users from xbuild to msbuild, while we want it to be as easy as possible we definitely don't want to implement "bugs" in msbuild to match xbuild behavior (to the largest extent possible). "Bug" is a stretch here, but it's definitely not behavior we would choose (at least in hindsight).

Few options we talked about:

1. Keep $(OS) as is: Windows_NT, OSX, Unix
   1. OS override in the xbuild targets fork (if possible).
   2. Breaking change for xbuild -> msbuild.
2. Match xbuild behavior for $(OS): Windows_NT, Unix
   1. Rename the current $(OS) to something else and keep OSX in that one.
   2. Add $(OSPlatform) property, match OSPlatform Linux, Windows, OS. Document to prefer $(OSPlatform) for .NET Core.
3. Diverge the #if code between Mono and Core and keep both implementations.

Personally I think this should not be done in MSBuild but passed off to the Runtime. The closest thing I know of there would be to use OSPlatform. Unfortunately that a) doesn't include Unix at all, b) Windows_NT is changed to Windows, and c) sadly because of the way that's implemented MSBuild would have to change to add another value. What I don't really want to do is keep $(OS) as legacy for xbuild compat and add a 2nd way that's again custom to MSBuild (which is basically 2.i) for those who do want to distinguish.

Also for the statistics @jonpryor mentioned, most of those 1600+ hits are '$(OS)' != 'Windows_NT' so those would not break. Not that it makes it much better since there are exceptions, but it is much smaller than 1600.

Thoughts? We will discuss this again during our team triage tomorrow.

[dsplaisted]

I would lean towards option 2, matching the xbuild behavior, as right now it has a lot more adoption than .NET Core MSBuild and it is better to keep this behavior consistent if possible.

The OSPlatform APIs don't allow you to get the name (by design), they only allow you to check to see if you are on a specified OS. So if we want to expose this functionality, I think we should do so as an intrinsic function instead of a property, ie IsOSPlatform('OSX').

[AndyGerlicher]

Team Triage: Marking as up-for-grabs. We would like to make $(OS) follow the xbuild behavior (Windows_NT, Unix) and implement what @dsplaisted mentioned (IsOSPlatform('OSX')).

[rainersigwald]

We talked about this a bit more. It's unfortunate that IsOSPlatform is CoreCLR-only, so we might need to have a special case for running on the full framework that returns false for anything that's not Windows.

[akoeplinger]

@rainersigwald afaik you can use the System.Runtime.InteropServices.RuntimeInformation package which has these new APIs on full framework too, but @ericstj can confirm.