dotnet "tool" issue when using custom nuget.config + globalPackagesFolder

[JHorvath-MaxetaTech]

When using a custom nuget.config that defines globalPackagesFolder along side a .NET 5.0 solution (to provide a local path to restore package to)

<?xml version="1.0" encoding="utf-8"?>
 <configuration>
  <config>
    <add key="globalPackagesFolder" value="..\lib\nuget" />
  </config>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
</configuration>

Performing a dotnet tool install %tool_name% --version %version_number% will inject that tool's NuGet package appropriately into the specified globalPackagesFolder path, as well as generate an appropriate file under the global toolResolverCache folder:

%userprofile%\.dotnet\toolResolverCache\1\%tool_name%

However... the PathToExecutable reference inside the file will then never change (per tool version installed). Performing a second dotnet tool install for the same tool/version in a separate similarly setup solution, will leave the PathToExecutable value unchanged (despite the fact the file does appear to be touched). If the original solution is ever removed the tool then breaks across the board and can not be fixed without manually modifying/deleting the file.

Neither dotnet tool restore nor dotnet tool update appear to update the PathToExecutable either, forcing all tools to be installed globally first before ever using a custom nuget.config.

I understand the point of the toolResolverCache is based around consolidating tool installations globally, but if a custom nuget.config is supplied with a solution, it seems like the tool NuGet packages should be referenced in the same manner as any other NuGet Package by the globalPackagesFolder reference first, using the toolResolverCache as a global fallback.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[0x53A]

I have hit this issue multiple times now, and it is really painful

[iamjplant]

This seems closely related, or maybe even a duplicate of #11432