SDK users can update their installed runtime and SDKs

[marcpopMSFT]

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]

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]

@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]

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]

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]

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]

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

• Hard-code downloading assets from MS URLs.
• Don't take source-build into account.
• Don't take package managers into account.

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

• .NET is primarily delivered to users via installation orchestrators (Visual Studio, Linux Package Managers, WinGet/Home Brew).
• The CLI should prefer user/repo local installs.

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]

I see dotnet/install-scripts#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]

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.