Should dotnet --info surface a global.json in the mix?

[guardrex]

Steps to reproduce

1. Create a project with a global.json in a parent folder that sets the SDK.
2. Dr. Frankenstein on your creation 👹 for months (and forget the global.json is up in the parent folders somewhere).
3. Prep to upgrade the project: Install a newer SDK.
4. 😢 Can't figure out why tools aren't upgraded for the project.

Expected behavior

dotnet --info tells you that an intervening global.json (with its path) is holding back the SDK.

Actual behavior

😵 Can't figure out why the SDK is stuck on an older version.

Source

Slack chat: This just happened to a dev today, and it happened to me once several months ago.

I understand if u lean "DNF" on this suggestion; however, consider that if it would be easy to surface that the SDK is fixed by a global.json in the output of dotnet --info, WHY NOT??? I speculate it would save many devs from some pain.

[dasMulli]

This may be more important than before since VS 15.3+ now resolves the msbuild SDKs used via hostfxr and respects global.json.

[vcsjones]

This we briefly touched on in #6569:

I think we should leave it like this because that is the fastest way to check on what version you are and as you quite nicely said, it is technically correct behavior. We could see if a feature can be made at some point in the future that would list out the SDKs installed, but I'm not too sure if this is the way forward. Need to think on this.

I agree that something should be developed here, I lost some time to this once, myself.

[guardrex]

@vcsjones That's not what I'm suggesting. All I'm saying is that if there is a global.json that's setting the SDK that the output could tell u that. I'm not talking about listing SDK's ... just state which global.json file is controlling the version. I'm also not talking about dotnet --version; I'm referring to dotnet --info, where there's more flexibility.

[nguerrera]

Good idea!

[guardrex]

Too many times now on Slack a dev shows up with "I just upgraded my SDK, but I can't see the upgrade in the project." There's this little dance where someone has to tell them to go look for a global.json somewhere above the project ... sure enough ... six months ago they stuck one up there to "freeze things" while they worked on a project and totally forgot about it.

The only other thing I can think of for surfacing this beyond dotnet --info output is to call it out on all builds and publish ops ... u know ... "Building with XXX SDK (path to global.json here)" ... "Publishing with XXX SDK (path to global.json here)."

[dasMulli]

global.json death toll upgrading to 2.0.0 over the last two days I've heard of: 8. (@ctolkien being the latest addition).
Definitely worth adding to --info if possible.

[vcsjones]

All I'm saying is that if there is a global.json that's setting the SDK that the output could tell u that

Sure, I understand what you're asking. I brought it up because some people are confused by the output of dotnet --version because global.json is forcing it to a specific version. I think --info would be a good place to put things, but frankly I think some people are still going to be confused.

The only other thing I can think of for surfacing this beyond dotnet --info

That's where I think we should be heading with this. I don't think dotnet --info is going to be the first place people go to look some something is "weird".

[livarcocc]

We are looking into a mine re-haul of dotnet --info on https://github.com/dotnet/cli/issues/7926.

I am closing this issue in favor of that one that has traction.

cc @KathleenDollard to add the idea of indicating that the SDK version is coming from a global.json.