The approach we use at work is that developers can build their own version of the library NuGet packages for debugging purposes. By having a local developer package respository they can use those packages for debugging / testing without having to make 'official' releases.
The local package repository can be just a directory on your machine in which you put your locally build packages. Then by updating your NuGet configuration file you can specify that NuGet should search your development directory first before searching the company wide respository.
Another approach is to build a new version of the library and then to copy the library binaries over the top of the existing binaries in the solution package directory. e.g. if you have version 2.0 of your library called MyCoolLibrary
and you want to debug MyCoolApp
then you could copy MyCoolLibrary.dll
to the package directory of the MyCoolApp
solution, over the top of of the existing version 1.5 of the MyCoolLibrary
. NuGet shouldn't touch the assemblies under normal circumstances so that would work for a developer test. Note though that this won't allow you to find problems with the NuGet package if you have actually made updates there, e.g. adding new assemblies or changing strong name keys etc. etc..