There is no way to force a true reinstall of a package from the actual source

[bitbonk]

During development we would like to make changes to code in a nuget package, build it locally and then test and debug these changes in a different solution that consumes this package. This "inner loop" happens many times during the day.

Unfortunately because of the way NuGet currently works, there seems to be no decent workflow to support a short inner loop like this unless I increment the package version manually in the csproj for each little change I want to try out.

Forcing a restore of the package like this

dotnet restore --source c:\temp\nuget --no-cache --force

will not reinstall the package from c:\temp\nuget. The option --no-cache does not affect global-packages. The above command will just reinstall the outdated package that is in the %userprofile%\.nuget\packages cache. (I just learned today that you do no consider global-packages to be a cache, so that explains that).

Also the above command would potentially restore all packages again. This could potentially be time consuming and makes the inner loop longer. I have no way to tell NuGet to restore just that one package I changed.

Also there is no dotnet cli command to clear the global-packages for just a single package. All I can do is to clear the complete "cache" using

dotnet nuget locals --clear global-packages

So the current workflow that we currently use is either to delete the package from %userprofile%\.nuget\packages manually before we do a restore or to manually override the changed dll directly in the folder where it was referenced by the consuming project, e.g. %userprofile%\.nuget\packages\PackageId\1.0.0\lib\netstandard2.0\Foo.dll.

So it would be very helpful if there would be something like

dotnet nuget locals --clear <PackageId> global-packages

to delete a particular package from the "cache" or

dotnet restore --source c:\temp\nuget --package <PackageId> --really-force

to truly force a reinstall of a specific package from the actual source.

NuGet product used: dotnet.exe
NuGet version: 4.9.2.0
dotnet.exe --version: 2.2.102
OS version: Win10 v1809

[bitbonk]

#5619

[zivkan]

closing as a dupe of #6579.

As stated in that issue, a workaround is to use nuget.config to change your globalPackagesFolder to somewhere that gets cleared between CI tests, or as needed.

[bitbonk]

I have been trying this approach and failed: #7692

[gioce90]

I was searching for something like this to improve the inner-loop package development. I also open the feature request #13918 and I have made a first "home-made" solution as pointed out here

[gioce90]

@bitbonk @zivkan Hi. 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!