-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable users to install unlisted version of tool if specify the exact match of the version of the tool #36021
Conversation
63086b7
to
b0f6e36
Compare
src/Tests/dotnet.Tests/CommandTests/ToolInstallGlobalOrToolPathCommandTests.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
I have a few comments but I'm marking this as approved since I'll be out tomorrow.
src/Cli/dotnet/NugetPackageDownloader/NuGetPackageDownloader.cs
Outdated
Show resolved
Hide resolved
src/Tests/dotnet.Tests/CommandTests/ToolInstallGlobalOrToolPathCommandTests.cs
Show resolved
Hide resolved
…sted tests in CI; fix wording and version
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Added When you commit this breaking change:
Tagging @dotnet/compat for awareness of the breaking change. |
Customer Impact
In .NET 8 we made a breaking change that changes the current .NET tool installation mechanism from restore a local temporary project to downloading the .NET tool from NuGet. This change was introduced because this previous mechanism has number of side effects, often show up as flaky restore errors because MSBuild concepts like Directory.Build.props, or other heirarchical notions, pollute the restore.
The change, however, disable users from installing unlisted tools. Previously, users were able to install unlisted tools per fix in #28951. However, since the mechanism of tool installation are changed, the unlisted tools' downloading are disabled by default. For users, installing unlisted tools are a useful method because it provides clarity and simplicity for those who write tools independently or do not share the tools to the public.
The intended way to fix this is to provide a feature to allow users to install the unlisted version but only if the user specify the exact match, i.e.
[version]
. (referred to NuGet package version reference). To add this feature, an unlisted parameter is passed to the NuGet API if a exact version is detected. Changes are validated by tests.Testing
Existing unit tests passed without changes. New tested are added to validate an unlisted tool can be installed with exact version match, and failed to be installed without the version match. The new testing scenarios pass with changes in the pull request.
Risk
Low. This change adds a feature that was missed from breaking change without adding complexity to the behavior.
Original description
Referred to some deprecated global tools get NuGetPackageNotFoundException when installing