Runtime: 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

[mmisztal1980]

@NickCraver any idea how to install 2.2.107 on a ubuntu box? I followed the instructions but I ended up with a higher version

[cmelgarejo]

This is needed for cross-platform development, Linux has 2.2.300 and MacOS 2.2.107, our global.json file is set to the .300 SDK and vscode c# plugin on MacOS does not parse the projects correctly then you have to change to .107, screwing up everytime you want to develop on MacOS, for the IDE to show no errors, or else there are like 11k + for example 😢

[dagood]

You can use the binary (tar.gz) installer for Linux to get 2.2.107. It's the .NET Core Binaries line, e.g. https://dotnet.microsoft.com/download/thank-you/dotnet-sdk-2.2.107-linux-x64-binaries. Not preferred, but the bits at least are there.

You can use apt list -a dotnet-sdk-2.2 to show the versions available on your distro, or browse:
https://packages.microsoft.com/ubuntu/18.04/prod/pool/main/d/dotnet-sdk-2.2/
https://packages.microsoft.com/ubuntu/19.04/prod/pool/main/d/dotnet-sdk-2.2/
(...and more.)

I'm not able to find a 2.2.107 SDK available as a Deb package. 😕 I opened https://github.com/dotnet/core/issues/2825 to track/discuss this.

Related discussion: https://github.com/dotnet/core/issues/2721 (Installing old SDK versions on CentOS/Fedora)

[vitek-karas]

Proposed design which should include this feature request is discussed here: https://github.com/dotnet/designs/pull/71

There's also ongoing implementation in https://github.com/dotnet/core-setup/pull/6953

[HEskandari]

This broke a local build of ours when I updated my Visual Studio from VS 16.2.5. to 16.3.4. The reason is that the new update included .NET Core v3 which is what was picked to build our solution. Fixing the .NET Core SDK using a global.json file to say 2.2.402 broke the build on the build agent since that's not the exact SDK version installed there.

[vitek-karas]

In 3.0 we now introduced new options to hopefully solve these issues. The design is here: https://github.com/dotnet/designs/pull/71 (working on actually merging it to master).
The code changes are here, and the PR has some nice short description of the new options: https://github.com/dotnet/core-setup/pull/6953

Typically it's enough to add rollForward: feature or rollForward: minor (depending on what exactly you want/need) to the global.json while specifying the minimum version required.

Note that the changes are made in the shared components of .NET Core, so it's enough to have 3.0 on the machine and it will work for any version of the SDK. (Basically the dotnet.exe and more importantly hostfxr.dll must be 3.0).

[TheXenocide]

In 3.0 we now introduced new options to hopefully solve these issues. The design is here: dotnet/designs#71 (working on actually merging it to master).
The code changes are here, and the PR has some nice short description of the new options: dotnet/core-setup#6953

Correct me if I'm wrong, but this only works for the .NET Core SDK used under the "sdks" section of global.json, right? There's no wildcard/latest/roll-forward behavior available for anything under the "msbuild-sdks" section? We're having an issue trying to get our local builds to use the latest version of our own SDK