RuntimeInformation.IsOSPlatform does not actually check OS platform

[natemcmaster]

dotnet/corefx#1999 added API's which creates an API contract to detect OS platform (#1017).

However, the implementation of dotnet/corefx#1999 does not work correctly. The current implementation does not actually examine the current OS at runtime. This means System.Runtime.InteropServices.RuntimeInformation.IsPlatform can lie if the wrong package is used at runtime (see aspnet/Microsoft.Data.Sqlite#121, for instance.)

Repro

1. Download and use a "Windows" version of System.Runtime.InteropServices.RuntimeInformation.dll.
2. Run on OSX or Linux CoreCLR
3. Call RuntimeInformation.IsPlatform(OSPlatform.Windows).

This returns true on all platforms, including OSX and Linux.

[akoeplinger]

/cc @Priya91

[Priya91]

The design of OSPlatform apis was to have different binaries for different platforms, which was approved during API review. It is expected for the target platform to have the right binary, just like any other corefx libraries. Deploying a windows System.Diagnostics.Process.dll on Linux machine will not work. Please target the platform correctly.

[natemcmaster]

Yes this is a problem with DNX (see aspnet/dnx#2594 and aspnet/dnx#2387).

Regardless of what was approved in the API review, I still suggest we change how this is implemented. Using different binaries is fragile. Something as important as "which OS is this" should actually check at runtime which OS is running.

[Priya91]

@natemcmaster : Changing the implemenatation to check for OS at runtime have to be done using PInvokes, which is a fragile process. Discussed offline about this with @ericstj. Calling Linux/OSX apis on Windows is definitely not allowed, this implementation will be rejected by WAC for windows store apps and moreover there is a perf issue to catch runtime exceptions on failure to PInvoke.

We will have a packaging mechanism to target the right dlls based on platform, and it is a work in progress. When that comes up, you will not be picking the wrong dlls. @ericstj can elaborate more on this story.

[natemcmaster]

@Priya91 thanks for the explanation. A packaging mechanism will help with this issue.

I also expect the current implementation has perf in mind. The string compare is fast and works well assuming the binaries are loaded correctly. PInvoke or native calls adds more overhead to this call and complexity to the code.

As an alternative, would it be possible to extract OS/runtime info from CoreCLR itself? These binaries are already compiled to work on darwin/linux/bsd and can better guarantee accuracy of IsOSPlatform.

[Priya91]

@natemcmaster The OSPlatform is a portable library, and we don't take dependencies on coreclr. If we need to do that, then this API should live close to coreclr, in mscorlib. And with .NET Core, we try to decouple libraries as much as possible, away from mscorlib, to have shorter implementation libraries. The specified scenario will not exist once the packaging story is in place, and hence at the moment the suggested scenario is not a compelling reason to move the library closer to runtime.

For more information on .NET Core and the need for portable class libraries please refer this article

[natemcmaster]

Ok. Thank you @Priya91 for taking time to explain the justification.

[Priya91]

@natemcmaster No problem :) You can work around this by bin placing the right binaries for the time being. Hoping that solves your problem, closing this issue.