Open AraHaan opened 3 years ago
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.
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.
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?
I think there are three separate things being discussed in this issue:
Microsoft.NET.Sdk
) through a CLI gesture (@marcpopMSFT).Microsoft.NET.Sdk
through a NuGet mechanism rather than a separate install gesture (@FiniteReality)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).
@rainersigwald From how I understood the issue, it's more like:
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
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.
@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.
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.
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?
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.
Will this be looked into in 7.0.2xx or 8.0.1xx?
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.
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:
--prerelease
switch to install the latest prerelease version and uninstall the older ones.Microsoft.NET.Sdk
currently without saying things like/1.0.0
at the end of it for example.