Poor experience for .NET tool installed by unsupported SDK

[vcsjones]

Installing a .NET global tool with an SDK that is lower than the tool's required SDK leads to a confusing error message:

The settings file in the tool's NuGet package is invalid: Settings file 'DotnetToolSettings.xml' was not found in the package.
Tool 'azuresigntool' failed to install. Contact the tool author for assistance.

AzureSignTool 7.0.0 requires .NET 10, but if a user has .NET 8 installed, they will receive that message.

Steps to reproduce:

1. Install .NET SDK 8.0.xxx. Ensure anything newer than 8.0 is not installed.
2. Do dotnet tool install --global AzureSignTool --version 7.0.0
3. Observe the error message.

Ideally, something like "AzureSignTool 7.0.0 requires .NET 10. Please install .NET 10 <insert aka.ms link here>" is displayed.

[vcsjones]

For what it's worth I think this regressed at some point. Looking at an older issue from one of my users, it used to be something like

error NU1202: Package AzureSignTool 4.0.1 is not compatible with net70 (.NETFramework,Version=v7.0) / any.
 Package AzureSignTool 4.0.1 supports: net6.0 (.NETCoreApp,Version=v6.0) / any                                                                                     

The tool package could not be restored.

That gave folks some kind of warning that their .NET SDK is not up to date.

[baronfel]

You're correct - we regressed in .NET 7 when we moved from dotnet restore powered tool downloads to direct usage of the NuGet APIs. Restore does a lot more post-download checks, and restoring some set of those is the specific thing we should do in the SDK.

We should not go back to the days of abusing Restore for this for many reasons - perf among them.