You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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
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
The text was updated successfully, but these errors were encountered: