`dotnet tool install --local --no-cache` ignoring the `--no-cache` flag for locally built packages

[conlanpatrek]

Describe the bug

dotnet tool install --local --no-cache is ignoring the --no-cache and is installing locally built tools from the nuget cache.

To Reproduce

I have created a simple repro here: https://github.com/conlanpatrek/dotnet-cach-bug-repro
It includes a sub-project (/Package/Package.csproj) that builds a simple one line tool locally.

I'll provide the str here for convenience:

1. pack a local tool into a nupkg file
2. install that local tool locally using dotnet tool install
3. make a change to the local tool source, and repack using the same version
4. reinstall that local tool using dotnet tool install and specifying the --no-cache flag.

Expected: You install the newly packed bin of the tool
Actual: The cached version of the tool is reinstalled, ignoring your --no-cache flag.

Workaround

You can manually clear the nuget cache using nuget locals all -clear and run dotnet tool install again to get your fresh build.

Further technical details

.NET SDK:
 Version:   7.0.202
 Commit:    6c74320bc3

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.0
 OS Platform: Darwin
 RID:         osx.13-x64
 Base Path:   /usr/local/share/dotnet/sdk/7.0.202/

Host:
  Version:      7.0.4
  Architecture: x64
  Commit:       0a396acafe

.NET SDKs installed:
  6.1.415 [/usr/local/share/dotnet/sdk]
  3.1.426 [/usr/local/share/dotnet/sdk]
  7.0.403 [/usr/local/share/dotnet/sdk]
  5.0.408 [/usr/local/share/dotnet/sdk]
  8.0.100 [/usr/local/share/dotnet/sdk]
  6.0.405 [/usr/local/share/dotnet/sdk]
  6.0.406 [/usr/local/share/dotnet/sdk]
  6.0.407 [/usr/local/share/dotnet/sdk]
  9.0.102 [/usr/local/share/dotnet/sdk]
  7.0.103 [/usr/local/share/dotnet/sdk]
  7.0.200 [/usr/local/share/dotnet/sdk]
  7.0.202 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 3.1.21 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.32 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.14 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.15 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.21 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.32 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.14 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.15 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

• VSCode v 1.81.0, but I'm not using integrated tools I'm using the CLI.

[Markliniubility]

This looks interesting. Can I investigate in this?

[dsplaisted]

It looks like we are ignoring this option for local tool installs and restores. Probably what we need to do is to create a RestoreActionConfig with the appropriate settings, and pass it through to the NuGetPackageDownloader that is created in ToolPackageDownloader.

@Markliniubility We'd be happy to review a PR for this if you'd like to send one.

[Markliniubility]

It looks like we are ignoring this option for local tool installs and restores. Probably what we need to do is to create a RestoreActionConfig with the appropriate settings, and pass it through to the NuGetPackageDownloader that is created in ToolPackageDownloader.

@Markliniubility We'd be happy to review a PR for this if you'd like to send one.

Thanks for the note! While I totally agree with this idea and it is the most possible solution imo, unfortunately, passing the RestoreActionConfig into NuGetPackageDownloader doesn't solve the issue (maybe it help with the issue) as I tested locally.

I wonder if several download/install related functions called from https://github.com/dotnet/dotnet are causing the bug. (e.g. https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/NugetPackageDownloader/NuGetPackageDownloader.cs#L114C104-L120 could be handling cache context wrong)

[JL03-Yue]

@Markliniubility Thanks for the question! I believe dotnet tool install --local might have this problem. This applies to local tools as we can restore local tools from manifest files. We'd be very happy to review if you'd like to have one🙂

[Markliniubility]

It looks like we are ignoring this option for local tool installs and restores. Probably what we need to do is to create a RestoreActionConfig with the appropriate settings, and pass it through to the NuGetPackageDownloader that is created in ToolPackageDownloader.
@Markliniubility We'd be happy to review a PR for this if you'd like to send one.

Thanks for the note! While I totally agree with this idea and it is the most possible solution imo, unfortunately, passing the RestoreActionConfig into NuGetPackageDownloader doesn't solve the issue (maybe it help with the issue) as I tested locally.

I wonder if several download/install related functions called from https://github.com/dotnet/dotnet are causing the bug. (e.g. https://github.com/dotnet/sdk/blob/main/src/Cli/dotnet/NugetPackageDownloader/NuGetPackageDownloader.cs#L114C104-L120 could be handling cache context wrong)

@nugetlurker Suppose I pass

SourceCacheContext {
      NoCache = true,
      DirectDownload = true,
      IgnoreFailedSources = _restoreActionConfig.IgnoreFailedSources,
  };

in to CopyNupkgToStreamAsync, and the downloader still uses the cache as this issue mentioned, is this expected?

Thanks!

cc @JL03-Yue @dsplaisted