Home: How to always get the newest prerelease version of NuGet package without deleting the cache

[CodingSpiderFox]

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):

VS UI

NuGet version (x.x.x.xxx):

3.4.4.1321

dotnet.exe --version (if appropriate):

1.0.0

VS version (if appropriate):

OS version (i.e. win10 v1607 (14393.321)):

Windows 7 x64 (6.1.7601)

Worked before? If so, with which NuGet version:

No

Detailed repro steps so we can see the same problem

1. I have a packageA from which a prerelease version is created on my CI system (packageA 1.0.0-prerelease).
2. Now I change something in the prerelease package which has impact on packageB which uses packageA 1.0.0-prerelease.

3. The CI system builds the new revision overwrites the old prerelease packageA with the same name (packageA 1.0.0-prerelease) on the NuGet server (Artifactory).

4. When I open the solution for packageB and restore the nuget packages, the old version of packageA from the NuGet cache is used, I do not get the new published version.

5. I don't notice that the change in packageA broke something in packageB because the old version of packageA from the cache was used.

6. I want the package to be downloaded every time without manual interaction such as clearing the cache. Attaching the revision or build ID to the suffix (e.g. prerelease) also does not work because updating would also require manual interaction (either search+replace or upgrading through VS UI).

How can I solve this (maybe through changing the versioning paradigm for the prerelease packages if it makes sense)

Best regards

[MV10]

I request a "do not cache" setting at the individual package reference level.

I often work on several related libraries at once, all packaged to a local folder during development. The problem described by the OP applies here. Additionally, there is no point in copying these to a cache, they're already on the local drive.

I work on at least one large open source project that does deploy prerelease packages to NuGet.org, so a blanket policy that applies to prerelease would not be ideal. They can remain in this state for months before promotion, during which time many devs would be constantly retrieving the same file.

This is a major pain-point, I'm glad to see it has Priority 1. Hopefully there will be a corresponding VS GUI implementation (I see the "CLI" area tag but not all of us are fans of the command-line).