Make global.json "sdk/version" support min/max, or wildcards

[kierenj]

Today, I tried to deploy to Azure App Services, but they had updated to the latest tools SDK (preview3). This broke the build for my project.

Eventually, I found that I can specify an sdk/version to use a different version of the SDK. However, App Services have a range of versions installed, and the previous version I had (1.0.0-preview2-003133) wasn't an option - they have 1.0.0-preview2-003131.

I had to add a custom deployment script to copy in a different production version of global.json.

It would be great if there was a version range option of some sort here. I'd love to specify 1.0.0-preview2-*.

Moved from https://github.com/dotnet/cli/issues/4794

[gkhanna79]

@ramarag @schellap PTAL

[natemcmaster]

+1. Would also be nice to have an option such as "preferPrerelease" to opt-in to latest unstable installation even if a stable SDK version is installed. cref https://github.com/dotnet/core-setup/issues/1664#issuecomment-285140280

[gkhanna79]

CC @livarcocc as this is in the CLI/SDK policy resolution.

[dasMulli]

I suppose this is - or a different roll-forward behavior- is now more important with VS 15.3+ picking up the used SDK by calling into hostfxr through its SDK resolver.

This would mean that installing a daily build of a 2.1.0-** CLI would make a released version of vs 2017 15.3 pick up that version and build all your production projects with a preview SDK without users noticing. (Installing a 15.4 / 16 /.. VS version side-by-side would probably already cause that)

[NickCraver]

We'd like this to be a feature as well, for several scenarios. For build servers, we don't want to pin a specific version for things that are simple. We are only with 2.1.*. Please don't make us specify each release there. For example just this week AppVeyor broke on us. We did nothing, this isn't the SDKs fault, but it offers (as far as we know) few mitigations other than a full install on every platform every time for every build. As of writing this, Ubuntu images only have 2.1.500 and Windows images only have 2.1.403.

Can I build on 2.1.403 fine? Yes. Can I build on 2.1.500? Yes. Can I do this with one set of code? No. global.json prevents this today, it's too specific only.

A related situation happens locally. I have 2.2 previews installed. I have 3.0 previews installed. I have a team of developers without those. 3.0 is the default and it's broken in various ways. That's okay, it's a preview. That's why I'm testing it. But how do I work around it? global.json is the path, but I'm then forcing every team member to install a very specific SDK. And roll it forward over time, etc. Note: VS has no support for this, from everything I've seen it's still some abstract thing in the root that is foreign to most developers and only used as a workaround to a problem.

What I want to do is just:

{
  "sdk": {
    "version": "2.1.*"
  }
}

In short: if I have to think about which version I'm using (especially as fast as everything is shipping), the more I'm going to hate it. It should just work as much as possible. Floating versions would further that goal. It's opt-in behavior, can we have that?

Or even more generally: I want some things to run pre-release SDKs, and others to be on stable SDKs. Latest stable as an option we never have to touch again would be equally welcomed here - that's the behavior we generally want.

[clairernovotny]

Apparently there is a way to specify "latest prerelease"

{
  "sdk": {
    "version": "3.0.100-preview"
  }
}

Because there is no exact version that matches, it'll look for the latest, which would be something like 3.0.100-preview.9754.

[NinoFloris]

We're hit by appveyor behavior too... really can't wait for sdk version range pinning

[dasMulli]

Also see @vitek-karas' suggestion for NuGet-style version specifications at
https://github.com/dotnet/core-setup/issues/3623#issuecomment-441772412

[mmillican]

To reiterate what @NickCraver said, supporting ranges or at least minimum versions in global.json would be huge. Currently, we have ~15-20 ASP.NET Core projects and its extremely hard to keep them all in sync and making sure all devs (and build servers) have the correct version(s) of the SDK installed.

[mmisztal1980]

Is there any progress in this area? I've just been hit by this, trying to develop a solution on VS 2019 and VS 2019 on MacOS,

On MacOS the latest dotnet SDK version I can use is 2.2.107, which appears to be unavailable for Windows downloads. This is seriously impedes x-plat development

[NickCraver]

Unsure about progress here, but to unblock you can find 2.2.107 for Windows on the full download list: https://dotnet.microsoft.com/download/dotnet-core/2.2

[mmisztal1980]

Thanks @NickCraver no idea why I haven't spotted it earlier