如何强制包管理器更新具有相同版本的Nuget包？

Question

How can Update be enabled even though the version number has not changed?

I'm developing a Nuget package. We're in the early stages, beta/testing. We don't change the version until testing is complete but we want to pass on the changed package for testing purposes. But the Package Manager does not see the change, allow Update, unless the version has changed, I can reinstall but I'd prefer the testers to be able to Update.

How can this be done while the version number stays the same?

Answer 1

Resurrecting this as we are in the same boat (converting a monolithic solution to a Nuget-ified microservices architecture). This method works, though its a bit tedious:

Go to NuGet options and click 'Clear All NuGet Cache(s)' Do a Nuget package restore on the solution. If this ends up failing due to (eg Newtonsoft.json being 'in use by another process') close all instances of Visual Studio & end task on all instances of MSBuild.exe + VBCSCompiler.exe. Restart VS and it should work.

Note that removing and re-adding the package will not work as it will still use the old cached version.

Answer 2

I just faced the same problem and my search brought me to here.

Normally we are using the AssemblyInformationalVersion field to specify prerelease suffixes, eg:

• 0.9.5-beta00001
• 0.9.5-beta00002
• ...

When enabling prerelease versions in the NuGet package manager, these packages are offered as well. As long as the suffix expression "increases", the package manager treats subsequent prerelease versions as update. It's important therefore to start with a well-thought suffix, as eg the following will not work: beta9 > beta10 ( beta9 is treated higher, as the fifth character is higher).

As soon as the suffix is removed, the package is treated as release and is offered as update to all prerelease packages of the same version.

But as life gambles with us, sometimes we identify a small bug or improvement in a just released library. It's always really annoying to increase the version number again for such a microchange, if the just released library even wasn't used anywhere, cause its release is minutes ago only.

For this case I tried the procedure outlined by Simon Storr, but it wasn't enough. I encountered the old version in the packages directory of our solution. After manually deleting it from there, it took the current package from somewhere. I am not sure if it downloaded the current package at this step, or took it from a more global packages directory that is located in the parent directory of the solution.

Note that there are multiple packages directories! The properties of the NuGet package in the Visual Studio references view of the project displayed the global packages directory only. But there was the new version already (checked this with ILSpy), while still the old version was copied to the bin directory.