Force no cache for single package source in nuget.config

[bpaczkowski]

We're using package version wildcards for some of our internal libraries to make it easier to update them, but as it stands now, they wont get updated to the newest version (matching the wildcard) without the use of the no-cache operator, which also applies it to nuget.org package source. Ideally it would be if no-cache was applied to all wildcarded packages, but if I could apply it to a single package source (our internal one), this would suffice.

[heng-liu]

Similar to #3116

[MV10]

When I'm creating or modifying a library, I will temporarily output the package to a local folder which is defined as a package source. Being able to turn off caching for that source would be a huge time-saver. Currently after rebuilding the library, I have to unload the solution that uses the package, manually delete the cached version, then re-open the solution to restore the package.

I was going to post a suggestion that local package sources shouldn't be cached at all (which is still probably a good idea), but more generally, having the option to disable caching per-source would be pretty useful.

I don't think that 3116 is related.

[MV10]

This does seem to be related: #6579

[MrAntix]

could we have a no-cache flag in the nuget.config?

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
     <add key="local" value="../nuget" no-cache />
  </packageSources>
</configuration>

[gioce90]

could we have a no-cache flag in the nuget.config?

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
     <add key="local" value="../nuget" no-cache />
  </packageSources>
</configuration>

@MrAntix I also requested this here #13918

[alex-davidson]

This no-cache="true" feature would solve my problem too.

We have a policy of putting private packages within the source repositories which use them. This eliminates dependencies on internal package servers, etc. Each major repository contains a nuget-local directory and a NuGet.config which adds it as a source. Publicly-available packages are acquired from the public feed as normal.

The problem is that when a developer updates a private package, their machine's global cache still contains old versions. Package restore may resolve old versions of these packages as dependencies of other packages. Such situations typically build fine on the CI servers too as they also have all of the old versions cached. But the build then fails on a new machine, or if the global cache is cleared.

As a workaround we could clear the global cache before every build, but re-fetching everything takes ages. We absolutely do want public packages to appear in the global cache and stay there.

But IMO there is absolutely no case ever when these private packages should end up in the global cache. They come from the local filesystem and do not need to be cached anywhere.

[gioce90]

I see that this specific request is mainly made to address the problem of developing packages on the local machine. I faced the same issue as you.
Forcing no cache for a specific source will improve the inner-loop development of a NuGet package on the local machine, yes, but this issue has been open since 2019... So, in the meantime, I created a solution to address this problem.

I recently decided to make my solution public by releasing a package called NuJet (https://github.com/gioce90/NuJet). It enhances the inner-loop development and testing process for NuGet packages, especially in local workflows.

Feel free to check it out—I’d love to hear your feedback!