DotNet.install version not being used if dotnet is already on path

[severisv]

Description

I have a few versions of dotnet SDK already installed in C:\Program Files\dotnet (which the Windows installer picks by default).

I have a project with a global.json that targets an SDK I have not installed.

Doing DotNet.install DotNet.Versions.FromGlobalJson correctly identifies that it needs to install a new version and installs it to C:\Users\sever\AppData\Local\Microsoft\dotnet.

Subsequent calls to the DotNet module don't find the recently installed version and fail.

Workarounds

1. Remove dotnet from path:
   The script now runs all the way through. This is obviously not a workable solution though.

2. Specify the location when installing the SDK. Not great because different build servers and different developers will have different preferences.

3. Specify DotNetCliPath. This works, but is kind of annoying as I haven't specified the location in the first place. Would be great if DotNet would just pick it up the same way it decided where to install it in the first place.

Am I missing something, or is something not working quite as expected?

It would be great if DotNet.install could add the freshly intalled version to path by itself, so that once the script was run the SDK would be available for development purposes. I tried

        DotNet.install (fun o -> { o with
                Version = DotNet.CliVersion.GlobalJson
                NoPath = false
        })

but I couldn't get it to work.

Soo, bottom line, I'm not quite sure if I'm asking for help or reporting a problem. Either way, thanks!

[matthid]

You need to "connect" install with the other commands, see https://fake.build/dotnet-cli.html for an example on how to do this. Let me know if this doesn't help.

[severisv]

This works, thanks! Just wondering though, why is it necessary to connect them when DotNet.install uses the default install location? Wouldn't the other steps know about it aswell?

Also, what is the NoPath setting here intended to do?

DotNet.install (fun o -> { o with
                Version = DotNet.CliVersion.GlobalJson
                NoPath = false
        })

[kblohm]

NoPath = false tells the installer-script to set the PATH, but only for the currently installing process. And because that is a child process it is pretty much a noop.

As far as i know, DotNet-Module searches the PATH, then the userDir (where you installed it), then the systemDir, thats why you have to set it by hand.

[matthid]

You either connect them or manage PATH by hand. Not sure what else we can do there?

[severisv]

Could it be an option that DotNet.install looks for dotnet on path, and installs the new version into the same directory as previous versions if the install path is not specified?

[matthid]

What if "C:\program files\dotnet" is the preferred location in PATH and fake cannot write there?

[severisv]

I didn't think about that. I guess it's impossible for Fake to install a new SDK into the same folder that dotnet is already running Fake from, as it would try to overwrite dotnet.exe anyway.

What if the algorithm for selecting the default dotnet location took SDK version into account (when global.json is present)?

I'd be happy to give it a shot if you think it's a reasonable idea :)

[matthid]

@severisv I don't think Create should have side-effects like calling dotnet --version otherwise feel free to send a PR which introduces a helper with the logic or some other way.