Installing new sdk versions through dotnet

[lewislabs]

I'm wondering if this is achievable, it's certainly something that's desirable from a portability standpoint.

If I specify an "sdk":{ "version": "x.y.z"} in the global.json, and i run dotnet build on a machine without the x.y.z version of the sdk, could dotnet go and install that version?

The main benefit of this is developer productivity and consistency of the build tools used across development environments for any given project.

[TheRealPiotrP]

This is certainly something we want to enable, though we won't be able to get to it for 1.0.0.

[lewislabs]

👍 thanks for the information @piotrpMSFT

[RheaAyase]

I do not think that this is technically possible everywhere (remember the multi-platform aspect?) Linux permissions.

[tmds]

I do not think that this is technically possible everywhere (remember the multi-platform aspect?) Linux permissions.

@RheaAyase Windows has permissions too 😄

[RheaAyase]

@tmds Well, at least we can see how much I know about Windows. :D

But I mean like... if I install dotnet and then run it, it has no permission to add new binaries. How would it even fetch - definitely not from our repo, therefor it wouldn't follow dnf update etc.... It's just... bad idea imho.

[livarcocc]

We have been talking about adding a dotnet install sdk command that could be used explicitly by the user to acquire an SDK. The first turn of the crank we have been talking about making this part of the SDK itself, which means the host would not be able to do that for you.

[RheaAyase]

No installing of anything via dotnet please. Bad bad bad thing.

[svick]

@RheaAyase Do you think it would be acceptable if dotnet install sdk just delegated to the existing platform installer?

So, on Ubuntu, dotnet install sdk 2.0.0 would run something like apt-get install dotnet-sdk-2.0.0 (and would need to be run with sudo). On RHEL, it would run the appropriate yum command. On Windows, it would download and run the installer.

[RheaAyase]

Do you think it would be acceptable if dotnet install sdk just delegated to the existing platform installer?

No it is not, I mean... KISS right? Why complicate the lives of dotnet engineers, what if someone will decide to create a new package manager tomorrow that won't follow the usual conventions? As you mention permissions are also a thing and running dotnet with sudo is a big no-no itself. It's overall really bad idea: it's a lot of unnecessary work, many potential issues, and it brings no benefit to the user at all - none...

[michael-hawker]

Just had my build in VS fail due to NETSDK1141 as I had a slightly older version of .NET SDK installed than the one in the global.json file.

dotnet --list-sdks

is such a handy debugging too these days, it'd certainly be convenient to just be able to go

dotnet install sdk

And get the one required, the latest, or a specific version.

Would save a lot of time.

The dotnet tool can already install tools, I know the SDK is a bit different, but would be handy.

Would also mean a whole GitHub action could go away:

      - name: Install .NET 6 SDK
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '6.0.x'
      
      # And become this looking at the project's global.json or something:
      - name: Install Required .NET SDK
        run: dotnet install sdk required

Especially as finding the right install link isn't always easy. I have 6.0.307 installed but need 6.0.403. I binged .NET SDK and the first link is the wrong one:

As the VS SDK is the 307 one which I have. I need the third link, but then that doesn't call out the SDK version just the runtime version until you click on the all downloads:

[NatElkins]

Just wanted to chime in here that having an installed .NET SDK and wanting to install another one as per a global.json in a new project you've checked out seems like an extremely common use case. I would love to see some command that installs an SDK based on the global.json, or via an explicit version flag. Basically the equivalent of this (https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script) but baked into the SDK tooling. The friction involved with the script is fairly high. And finding it took me about 30 minutes of searching.