search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.6k stars 1.04k forks source link

SDK users can update their installed runtime and SDKs #14960

Open marcpopMSFT opened 3 years ago

marcpopMSFT commented 3 years ago

Only update muxer is the problem. Need to both back ward and forward compact (a problem of host team) Do we update just patch version or across feature band or even across major/minor? How do we handle update of non-admin vs. admin install?

omajid commented 3 years ago

How you do you plan to handle the case where the runtime or SDK was installed through a package manager (apt/brew/dnf) ? Do you plan to query the package manager directly too? What happens when the package manager is lagging and doesn't have the updates?

marcpopMSFT commented 3 years ago

@omajid Getting our experience right on Linux especially wrt package managers is one of the reasons that this work is not going to come in until .NET7. We're planning on doing some groundwork this release to set us on a path to have this in .NET7. Once we have designs for this in the future, we'll post them for review and feedback.

omajid commented 3 years ago

Sounds good.

We're planning on doing some groundwork this release to set us on a path to have this in .NET 7

I am one of the package maintainers for the .NET packages on RHEL and Fedora. Please feel free to loop me in if there's anything Linux-distro related that I might be able to help with.

richlander commented 2 years ago

I would assume that this UX is straightforward to deliver with a package manager and that the primarily challenge is with the non-package-manager scenario. Is that right?

omajid commented 2 years ago

I think there's also some concern that the UX for the non-package-manager scenario might introduce confusion for package-manager scenarios. For example, if there's a (hypothetical) dotnet sdk update command that updates the SDK itself, what should it do when the .NET installation was done via the package manager? Should it redirect users to another command? Should it run the command itself? How does it know the exact command? And what if the desired update version isn't available?

richlander commented 2 years ago

I'm not a fan of new deployment features that do any of:

We need to switch to the following being the primary scenarios:

In the early days of the workloads feature, we had a plan where an installation orchestrator could install a manifest in a known location and the CLI would use that to produce error messages like:

This installation is managed by yum.
You can install the component you requested with the following command:

sudo yum install foo

Would that help?

mattinsp commented 1 month ago

I see https://github.com/dotnet/install-scripts/issues/476 is now linked to this issue, but this issue has seen no activity in over 2 years. What is the situation with this @marcpopMSFT ? .NET clearly lacks a sensible way of managing SDK versions and it's a similar problem to the one in the JS world that has been solved by numerous tools like nvm. It's odd that for .NET we have a global.json to specify version and roll forward rules but no way to actually manage installing the correct SDK version!

marcpopMSFT commented 1 month ago

We've had a number of internal discussions and customer development around what customers would want for an improved acquisition experience covering a new installer UI with selectable components, a CLI experience covering upgrade and uninstall, what customers might want on linux platforms, etc. We're not quite ready to outline a new experience design for feedback or propose a timeline as other work keeps taking priority. Hopefully in the coming months we can at least share some ideas in the designs repo to get feedback.