Fix dotnet path on wsl

[yazeedobaid]

Description

This PR filters the resolved paths for dotnet by OS in Fake.DotNet.Cli. Fixes #2573

As reported in the issue. If a dotnet version is specified in a global.json file and that version is not installed on WSL but on Windows, the Fake.DotNet.Cli will use dotnet installed on Windows - C:\Program Files\dotnet\sdk\5.0.201\

The issue with this is when it tries to find possible paths it doesn't check for OS combatapility. This PR checks for resolved path to have the intended file suffixed with it. So on WSL and Unix, it will be dotnet and Windows resolved paths will be excluded. Likewise, if it was on Windows, it will be dotnet.exe, and Unix and WSL paths will be excluded.

For the userInstalldir and systemInstalldir they follow the OS compatibility by setting path by executing OS. So no changes need to be done regarding them. The fault paths are a result of resolving them from environment variables that are not filtered by OS.

Using the following fsi snippet from issue:

#r "nuget: Fake.DotNet.Cli"
open Fake.DotNet
DotNet.exec id "--info" "";;

And the following global.json:

{ 
    "sdk": {
        "version": "5.0.201"
    }
}

I tested it out and got the following results:

On WSL

Installed SDKs:

.NET SDKs installed:
  3.1.407 [/usr/share/dotnet/sdk]
  5.0.201 [/usr/share/dotnet/sdk]

The result, the sequence is resulting paths that Fake.DotNet.Cli has resolved to:

seq ["/usr/bin/dotnet"; "/bin/dotnet"]
Runtime Environment:
 OS Name:     ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         ubuntu.20.04-x64
 Base Path:   /usr/share/dotnet/sdk/5.0.201/

And I have /usr/bin/dotnet a symlink to /usr/share/dotnet/dotnet

/usr/bin$ ls -al | grep dotnet
lrwxrwxrwx  1 root   root          22 Feb 17 00:21 dotnet -> ../share/dotnet/dotnet

On Windows

Installed SDKs:

.NET SDKs installed:
  2.2.207 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.302 [C:\Program Files\dotnet\sdk]
  3.1.407 [C:\Program Files\dotnet\sdk]
  5.0.103 [C:\Program Files\dotnet\sdk]
  5.0.201 [C:\Program Files\dotnet\sdk]

The result, the sequence is resulting paths that Fake.DotNet.Cli has resolved to:

seq ["C:\Program Files\dotnet\dotnet.exe"]
Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19041
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.201\

---

I have 5.0.103 installed on Windows, I set it on global.json and got the following result on WSL:

seq ["/usr/bin/dotnet"; "/bin/dotnet"]

No runtime environment has been listed.

[matthid]

I guess there was no easy way to test this?

[yazeedobaid]

@matthid No, I thought about how to simulate the WSL environment but didn't know how to do it. But I tested it manually.
I agree that this needs tests to cover this case.