Incorrect SDK version used when multiple SDKs are installed

[sbomer]

The version detection logic in tools.sh/ps1 will use a globally installed "dotnet" if the install directory contains the SDK version requested in global.json.

If there are multiple SDKs installed (one that happens to match the requested version), this can result in using a version later than the one requested. Together with #3763 this was resulting in local builds of coreclr using an incorrect SDK version in some cases.

[dagood]

In the meantime, a workaround that I think is working for me is to set DOTNET_INSTALL_DIR:

$env:DOTNET_INSTALL_DIR = "C:\git\core-setup-arcade\.dotnet"

[markwilkie]

cc/ @chcosta

[chcosta]

@sbomer, is this a separate issue or just capturing the resultant behavior from #3763 not behaving as expected?

[sbomer]

Apologies for the late response. This is a separate issue - the logic to fall back to a globally installed SDK can end up using a version that's different from the one requested independently of #3763. #3763 is just about inconsistent behavior of the extensibility point (which coreclr happens to use to turn off the global SDK fallback).

[chcosta]

Is this specifically related to your official builds or your local dev builds? For local dev builds, this is a generally desirable behavior.

[dagood]

Core-Setup uses use_installed_dotnet_cli=false to prevent roll-forward behavior because the SDK has breaking changes between versions, yet I ran into this problem when it used the installed SDK anyway. So in my case, this issue is just an expression of #3763.

SDK rollfoward in general is intended, new to 3.0: dotnet/core-setup#6953, dotnet/designs#71. I believe that means this issue can be closed as by design unless the version discovery is working differently than the spec when Arcade does it. (I'm not familiar enough with it to say.)

[sbomer]

@chcosta I only saw this in local builds (and I'm guessing the official/ci builds won't run into this because they probably don't have any newer SDKs installed globally).

For example, coreclr currently uses 3.0.100-preview7-012821, and I have a global install of version 5.0.100-alpha1-013789. When I run, for example ./eng/common/msbuild.sh src/build.proj, it uses version 3.0.100-preview7-012821 as expected. However, if I then install 3.0.100-preview7-012821 globally, the same command starts using 5.0.100-alpha1-013789 from the global install. If the roll-forward is desired, I'd expect it to be independent of whether I happen to have a global install of the version listed in global.json.

If I get rid of use_installed_dotnet_cli from coreclr's eng/configure-toolset.sh, I see the same behavior with build.sh (this is on an empty project, but it illustrates the issue):

>  ./eng/common/build.sh --projects `pwd`/eng/empty.csproj --build -v diag

Without a global install of 3.0.100-preview7-012821:

...
Target "CoreBuild: (TargetId:83)" in file "/Users/sven/src/dotnet/coreclr/.dotnet/sdk/3.0.100-preview7-012821/Microsoft.Common.CurrentVersion.targets"
...

With a global install of 3.0.100-preview7-012821:

...
Target "Build: (TargetId:83)" in file "/Users/sven/bin/sdk/5.0.100-alpha1-013789/Microsoft.Common.CurrentVersion.targets
...

[chcosta]

What is your expectation of behavior? As @dagood points out...

SDK rollfoward in general is intended, new to 3.0: dotnet/core-setup#6953, dotnet/designs#71. I believe that means this issue can be closed as by design unless the version discovery is working differently than the spec when Arcade does it. (I'm not familiar enough with it to say.)

[dagood]

It sounds like Arcade is inconsistently blocking roll-forward: (I guess because of the "is .NET Core installed?" capability test)

If the roll-forward is desired, I'd expect it to be independent of whether I happen to have a global install of the version listed in global.json.

[alexperovich]

Does the roll-forward block multi-level lookup? It looks like arcade looks for a machine wide install with the version it wants, if that version exists it just uses the machine wide install that may roll-forward. If that version isn't avaliable locally it downloads a local cli and uses it. The local install doesn't have anything to roll-forward to so no roll-forward happens.

[chcosta]

I don't think Arcade is being inconsistent, but there are certainly some code paths which are not using Arcade consistently.

https://github.com/dotnet/arcade/blob/master/eng/common/tools.ps1#L105

If you're not using standard Arcade scripts and just directly invoking msbuild.ps1, then you might not be getting this set since it only runs during "InitializeDotNetCli". If you're already doing custom stuff, you could wrap msbuild.ps1, or you can update msbuild.ps1/sh to set the variables as well.

[dagood]

TIL msbuild.ps1/sh isn't a standard Arcade script--I thought it was meant to be a way to handle automatic bootstrap and some Arcadey params when you need to call a specific target on a specific project file. Core-Setup uses it this way in the official build. (For my own dev builds, I've been settling into using build.cmd/sh --project and restricting myself to only running the Build target.)

[vlada-shubina]

Just run into same issue locally in dotnet/templating, upvoting. I wish there is flag that forbids using globally installed dotnet.
Another easy workaround is adding:
"sdk": { "version": "your-version" },

to global.json.