[Feature Request] Add dotnet sdk install to install Sdks from nuget sources.

[AraHaan]

For example let’s say currently projects use the MSBuildExtra’s notargets sdk to mark an csproj that should not be used to build code (only packages stuff into an nuget packages like an Sdk.props and an Sdk.targets file for custom Sdks) currently there is no way to know what is the absolute latest version and consume that one. I personally think this command would be useful because:

• the Sdk would be installed onto where the .NET Sdk is installed where the other ones bundled within are also installed.
• Such thing could open it up where instaling the .NET Sdk itself then it could bootstrap itself and run this command to install what would normally be bundled within the installer to all platforms (like Microsoft.NET.Sdk could be installed from a nuget feed instead of bundled within the .NET Sdk installer for example if that was possible)
• There would be an easy way to have it update (running the command would always download and install the latest one available but defaults to stable versions of them)
• There could be an option to do prerelease sdks as well with an --prerelease switch to install the latest prerelease version and uninstall the older ones.
• Projects that specify an specific version would not then need to specify it and instead use it the same way they can use the Microsoft.NET.Sdk currently without saying things like /1.0.0 at the end of it for example.
• Easier to keep track of and utilize bugfix releases automatically on those custom sdks without needing to worry if you are using the latest version of those and not being able to keep track of the releases of them all the time. This command would and could simplify it all and also great for CI scenarios as well.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[marcpopMSFT]

This is definitely something that we've been considering. dotnet sdk check is our down payment in this direction as we can now look up the details on what are the most recent releases for each feature band. Likely in the next release we'll look into having an update option that lets you update out of date sdks.

[FiniteReality]

I really hope that also means that we'd be able to install SDKs from NuGet. It would simplify the distribution model for SDKs massively; you just say "run dotnet sdk install My.Cool.Sdk" just like installing a tool. From what I can tell, the code for dotnet sdk check seems to only check a static json file from a CDN.

I know in the past the SDK was distributed via NuGet, but there's only versions from 2016 on NuGet, meaning that you moved away for good reason. Would it be possible, or even practical to move back?

[rainersigwald]

I think there are three separate things being discussed in this issue:

1. Getting local copies of NuGet-delivered SDKs through a CLI gesture (@AraHaan)
2. Getting up to date copies of the .NET SDK (Microsoft.NET.Sdk) through a CLI gesture (@marcpopMSFT).
3. Getting Microsoft.NET.Sdk through a NuGet mechanism rather than a separate install gesture (@FiniteReality)

[rainersigwald]

I am not in favor of the plan in the OP but there's a tweak that might help many of the same scenarios.

Projects that specify an specific version would not then need to specify it and instead use it the same way they can use the Microsoft.NET.Sdk currently without saying things like /1.0.0 at the end of it for example.

This is fairly risky for the same reasons that floating NuGet versions are risky, so I don't want to encourage it.

There would be an easy way to have it update (running the command would always download and install the latest one available but defaults to stable versions of them)

This, however, would be great.

So it might be interesting to have dotnet sdk update {sdkname} that would open global.json or the project, query NuGet, find the latest (optionally prerelease) version of the SDK package, and update the reference(s).

[FiniteReality]

@rainersigwald From how I understood the issue, it's more like:

• NuGet SDK references should go away (or at least, not be preferred)
• SDKs should be installed using dotnet sdk install
• dotnet sdk install should look on NuGet for an SDK (and/or its dependencies?) and install them to a special folder, like dotnet tool install
• MSBuild should locate SDKs in this special folder

That way, all SDKs installed on the system are in one location, and are managed similarly to tools. Optionally, like tools, I don't think it would be unreasonable to allow "local" SDKs to a solution or project, which would allow projects to be built using specific SDK versions rather than using whatever package the user has installed. However, a user would likely need to run a command like dotnet tool restore in order to gain access to these tools, which may make this inconvenient.

[AraHaan]

@rainersigwald From how I understood the issue, it's more like:

* NuGet SDK references should go away (or at least, not be preferred)

* SDKs should be installed using `dotnet sdk install`

* `dotnet sdk install` should look on NuGet for an SDK (and/or its dependencies?) and install them to a special folder, like `dotnet tool install`

* MSBuild should locate SDKs in this special folder

That way, all SDKs installed on the system are in one location, and are managed similarly to tools. Optionally, like tools, I don't think it would be unreasonable to allow "local" SDKs to a solution or project, which would allow projects to be built using specific SDK versions rather than using whatever package the user has installed. However, a user would likely need to run a command like dotnet tool restore in order to gain access to these tools, which may make this inconvenient.

Those 4 points are correct.

I think there are three separate things being discussed in this issue:

1. Getting local copies of NuGet-delivered SDKs through a CLI gesture (@AraHaan)

2. Getting up to date copies of _the .NET SDK_ (`Microsoft.NET.Sdk`) through a CLI gesture (@marcpopMSFT).

3. Getting `Microsoft.NET.Sdk` through a NuGet mechanism rather than a separate install gesture (@FiniteReality)

I used Microsoft.NET.Sdk as an example for installing as a custom Sdk however even if it's not possible to do it to Microsoft.NET.Sdk the other ones could possibly be done this way and have the installer at the end run the commands on that platform to install the other Sdk's that would normally be bundled inside from nuget.org (all updates to them would have to be pushed there or some other nuget feed)
dotnet sdk update would be used to update all of them (including Microsoft.NET.Sdk) so then the need to always download a new installer just to install the latest .NET Sdk could be less of an issue.

However how will it be able to also update the cli program at the DOTNET_ROOT?
Unless the dotnet cli program could be made aware of said command as well and after updating all the sdks installed to check for dotnet cli program updates and self update itself too.

[tillig]

I'm not sure if it helps or confuses the issue, but the dotnetsdkhelpers global tool has been around for a while and does a lot of this sort of thing. I'm just now getting into .NET 6 and noticed the new dotnet sdk check command conflicts with the global tool which isn't insurmountable but wasn't expected.

[tillig]

Also maybe related - the dotnet-core-uninstall tool seems to be in a maintenance mode and does not support uninstalling .NET 6. Is there a plan to support removal of SDKs and runtimes as well?

[AraHaan]

Yes I think when and if dotnet sdk install is added that it should be bundled with dotnet sdk uninstall which will entirely reverse what dotnet sdk install does while dotnet sdk update basically "upgrades" it by first installing the newer version (and then optionally) uninstalling the older version.

But yes I think this should not only work with SDKs within nuget feeds (like nuget.org) but could also be rigged with a special command to have it "install" or "upgrade" from public "preview" to "daily" .NET SDK builds (which I would love as it would then deprecate the need for the .NET Install Scripts not to mention the need to run the .NET SDK installers to "update" each time and also upgrade the runtime itself as a bonus). I can see great usage of such system then where CI's could be like dotnet sdk update --quality daily --upgrade-self where it would basically not only update all the nuget package based .NET SDKs that are installed from nuget sources but also the entire .NET SDK and the .NET CLI itself in a single command without the need to use the .NET Install scripts in order to upgrade all the normal .NET SDK files first.

[AraHaan]

Will this be looked into in 7.0.2xx or 8.0.1xx?

[marcpopMSFT]

Not 7.0.2xx. The SDK being able to install other versions of the .NET SDK we're hoping we can prioritize for 8.0.1xx. For the suggestions about downloading newer versions of sdks, we need to discuss more on prioritization and design.