If global.json has a B.S. version string for SDK, the CLI doesn't care

[TheRealPiotrP]

Moving from https://github.com/dotnet/cli/issues/3662 on behalf of @shanselman.

I verified that this still repros on:

Version  : 1.0.1
  Build    : cee57bf6c981237d80aa1631cfe83cb9ba329f12

---

Steps to reproduce

global.json:

{
"projects": [ "src", "test" ],
"sdk": {
"version": "foofoo"
}
}

Expected behavior

A warning? A freak out? Something?

Actual behavior

It uses the latest SDK/CLI without a whimper.

[gkhanna79]

If you enable COREHOST_TRACE=1, you will get log messages indicative of picking up the latest version. The design of the SDK activation is that in the event of invalid/non-existent versions, we pickup the latest version of the SDK.

[gkhanna79]

Please let me know if there are any outstanding questions that I can help with.

[gkhanna79]

I will close this for now as I believe the question has been answered. Please reopen if there are more questions on this.

[natemcmaster]

@gkhanna79 can we reopen this? This is actually a problem for us. The way that it silently falls back to some version makes it hard to enforce the global.json version. We want an error if the global.json sdk version isn't available. How do we do that?

[gkhanna79]

While this is implemented in the host, this is really the policy of CLI - how does it want such scenarios treated? Please work with @livarcocc if you really wish to have this behaviour changed.

[natemcmaster]

Hey @livarcocc I wish to have this behavior changed. As @shanselman originally wrote, I would also expect dotnet.exe to issue some kind of warning or error when the sdk version in global.json is invalid or not found. Can we have a discussion about implementing this?