[release/5.0] Target 5.0.0 shared framework in global tools #27599
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
$(TargetLatestDotNetRuntime)
in tool projects@(FrameworkReference)
item update if$(TargetLatestDotNetRuntime)
is disablednit: Move
$(PackAsTool)
settings togetherDescription
In 3.1.x servicing, the global tools shipped from the dotnet/aspnetcore repo had an undeclared dependency on the latest shared framework. Installing, say, the 3.1.9 version of
dotnet-sql-cache
went fine. But, attempts to run it fail with the output below unless the 3.1.9 shared framework was available.This PR is about avoiding the same issue in 5.0.1 and later.
Customer Impact
Customers will be able to install the latest 5.0.x global tools from dotnet/aspnetcore without also updating their installed shared frameworks.
Regression?
Yes but from way back in 2.1.x. Those tools worked fine because, though the runtimeconfig.json files we shipped referenced the latest version of Microsoft.NETCore.App, that package could be resolved when the tool was installed.
Risk (see taxonomy)
Incredibly small. The only possible risk would be a tool we ship from dotnet/aspnetcore depending on a fix in a serviced shared framework assembly. Such a dependency could be considered a breaking change and should be avoided.
Original issue and/or the PR to master.
Packaging impact? (if a libraries change)
None