Global.json is rolling backwards under some circumstances

[jaredpar]

I am trying to move the Roslyn repository over to the 2.1 SDK. In doing so I'm not seeing my SDK choices enforced in the way I would expect. Consider the content of my global.json:

{
  "sdk": {
    "version": "2.1.300-preview1-008174"
  }
}

Now compare that with the list of SDKS installed on the machine:

> dotnet --list-sdks
1.0.0 [C:\Program Files\dotnet\sdk]
1.0.0-rc4-004883 [C:\Program Files\dotnet\sdk]
1.0.2 [C:\Program Files\dotnet\sdk]
1.0.4 [C:\Program Files\dotnet\sdk]
1.1.0 [C:\Program Files\dotnet\sdk]
1.1.0-preview1-005051 [C:\Program Files\dotnet\sdk]
2.0.0-preview2-006497 [C:\Program Files\dotnet\sdk]
2.0.0-preview3-006923 [C:\Program Files\dotnet\sdk]
2.0.2-vspre-006949 [C:\Program Files\dotnet\sdk]
2.1.1-preview-007118 [C:\Program Files\dotnet\sdk]
2.1.100 [C:\Program Files\dotnet\sdk]
2.1.100-preview-007326 [C:\Program Files\dotnet\sdk]
2.1.100-preview-007354 [C:\Program Files\dotnet\sdk]
2.1.100-preview-007391 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.2.0-preview1-007622 [C:\Program Files\dotnet\sdk]

There are plenty there but none are the one specified in my global.json. Yet when I do commands like dotnet build, dotnet restore it functions without error.

Why isn't this being enforced?

[livarcocc]

what does dotnet --info shows you? It should show you the version you are using at the very top.

I think this is an issue with --list-sdks only, where it is likely using the MULTI_LEVEL_LOOKUP and not listing the SDKs next to dotnet itself.

[livarcocc]

cc @steveharter

[jaredpar]

Here is dotnet info

E:\code\roslyn> dotnet --info
.NET Command Line Tools (2.1.100)

Product Information:
 Version:            2.1.100
 Commit SHA-1 hash:  b9e74c6520

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.100\

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview1-25929-02
  Build    : 328fbf0657c4e3bab243460660583c429eaae001

[jaredpar]

Looks like this is "By design". Filed dotnet/core-setup#3807 on why this design is just not helpful.

[nguerrera]

I don't get why this is by design. It's supposed to be exact version or roll forward based on some policy if not found. Under no circumstances should the policy ever roll backward

[steveharter]

I think this is an issue with --list-sdks only, where it is likely using the MULTI_LEVEL_LOOKUP and not listing the SDKs next to dotnet itself.

--list-sdks will list both the current dotnet.exe as well as the global ones (C:\Program Files\dotnet\sdk)

Try setting COREHOST_TRACE=1 to help see how it's finding that sdk version.

[steveharter]

Looks like an issue in fx_muxer_t::resolve_sdk_version where it picks the highest version that matches [major].[minor].[patch/100] instead of returning an error if there is no compatible >=

[nguerrera]

Yes, that's that problem. It was somewhat mitigated by the fact that we don't push out previews of patches, but the problem is that we now have non-patches that look like patches to old hostfxr. It gets remitigated with 2.1 preview2 hostfxr that knows about Nxx patch scheme.

Further complication: VS/desktop msbuild resolver carries a copy of hostfxr at the moment and that doesn't have a code flow established to get the fix in 15.7. I thought using a preview2 build would unblock Jared here, but it doesn't do to that.

We have 3 options for that part of the problem (each with cons in parens)

1. Insert a 2.1 hostfxr into 15.7 resolver (crossing code-flow streams)
2. Change resolver to find hostfxr dynamically (delays fix until 2.1.300 is installed, but problem applies to 2.1.200 and 2.1.100)
3. Stop using hostfxr in the resolver (duplicating all of the SDK resolution logic in C#)

[nguerrera]

Option 4: backport /100 fix to 2.0.x hostfxr servicing along with fix to this.

[dsplaisted]

I ran into this while investigating dotnet/sdk#2045. I have 1.1.7 of the SDK installed but no higher 1.x version. A global.json specifying 1.1.8 rolls backwards to 1.1.7.

> dotnet --list-sdks
1.1.5 [C:\Program Files\dotnet\sdk]
1.1.6 [C:\Program Files\dotnet\sdk]
1.1.7 [C:\Program Files\dotnet\sdk]
2.0.0 [C:\Program Files\dotnet\sdk]
2.0.2 [C:\Program Files\dotnet\sdk]
2.1.1-preview-007094 [C:\Program Files\dotnet\sdk]
2.1.1-preview-007118 [C:\Program Files\dotnet\sdk]
2.1.1-preview-007187 [C:\Program Files\dotnet\sdk]
2.1.100 [C:\Program Files\dotnet\sdk]
2.1.100-preview-007326 [C:\Program Files\dotnet\sdk]
2.1.100-preview-007354 [C:\Program Files\dotnet\sdk]
2.1.2 [C:\Program Files\dotnet\sdk]
2.1.300-preview1-008174 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]

I've changed the milestone to 2.1.0, as I think we need to fix this.

[nguerrera]

That repro invalidates what I said about past mitigation and bumps the severity. Does it repro with rtm hostfxr?

[livarcocc]

This is a regression leading to the wrong SDK being picked. We need to fix this.

[livarcocc]

@johnbeisner I was under the impression this bug was fixed and that the correct behavior is implemented in 2.1.300. Can you confirm and close this bug if so?

[nguerrera]

AFAIK, binding to lower version across 100,200,300 boundaries is fixed in 2.1.300, but we will still bind to latest patch (even if lower than requested)? @johnbeisner is that accurate? If so, I think we need an open issue to track changing that. There was broad agreement to do that on the mail thread.

[IanKemp]

I know this is closed, but I just hit my head against what I think is the same issue after cloning and attempting to build the Roslyn repo. I have the 2.1.300 official version installed, but Roslyn wants to use 2.1.300-rtm-008866 (which it downloads during install, and is also set in its global.json). However when running the build in Visual Studio, it fails with the following errors:

Doing a bit of digging reveals that message is emitted here, which refers directly to this issue, hence why I'm guessing it's related.