As microservices architectures become more popular, so increases usage of NuGet as a way of sharing code amongst separate services. The last few projects I’ve worked on have typically contained a number of “Core” NuGet packages with shared code and interfaces that are consumed by one or more services in the solution. Our build pipeline will publish these NuGet packages to an in-house NuGet server.
This can cause a lot of developer friction when you’re working in one of the services and you decide you need to change one of the Core projects. Typically you’ll
- make the change to Core
- commit it
- (Perhaps raise a PR and wait for approval)
- wait for the build to publish new versions of the package
- and finally updated the package in your service.
Probably at least 20 min wait for all that to happen. And then you realise that your change didn’t quite work, so you have to go through the cycle again with another change.
Well, here’s a shortcut to that cycle and it’s pretty darn simple. Note that this only works if you’re using the newer .NET Core style .csproj containing <PackageReference>. Simply
- make the change in Core and compile it locally
- Copy the resulting dll(s) to your local NuGet packages feed folder. NOT the bin folder of your service, or the packages folder of your service. On my machine the local NuGet packages feed folder is
C:\Users\matt\.nuget\packages\.
As soon as the dll is copied, Visual Studio detects the change – you don’t need to tell it to update the NuGet packages or even compile!
Another surprise bonus of this – while debugging you can step into the Core code! You don’t need to mess around copying PDBs around or anything. I don’t know how it works, but Visual Studio seems to somehow know that the DLL you’ve copied into the NuGet folder came from your local machine and thus it knows where the source code for it is.
Obviously once you’re happy that your changes to Core are working correctly, then you can can commit them and consume an updated version of the package in your service as usual.
Anyway, hopefully this will speed up your local development as much as it has mine.
Matt's work blog 
Hey Matt,
great tip!
I wrote a NuGet package (how ironic) that adds an msbuild target to automate the process. Basically it creates a prerelease version ( my.package.1.0.1-dev ) that you can reference and will always be updated in the NuGet cache folder on build.
I noticed a strange behavior in Visual Studio though. When i make a breaking change in the NuGet package and i build the project referencing that package, Visual Studio will not pick up the change and show no error but the build fails (of cause).
The only way i found to get Visual Studio to notice the changed dll is to reload the project.
Have you seen a similar behavior? Do you know how to resolve this issue?
Hi Andre,
Personally I’ve found that when I have a breaking change, as soon as I copy the dll into my local cache folder, then VS will complain in the project referencing that package. I think I don’t even need to compile – intellisense usually picks up the breaking change.
I’m using Visual Studio 2017-style .csproj files, i.e. with PackageReference tags and thus no packages.config file. This might have something to do with it?
Matt
Hi Matt,
thanks for your awnser. I found my problem. I was replacing the nuget packages not the dlls.
Once i altered my msbuild task, it worked flawless.
Thanks for your help.
Andre
Hello,
Where is this documented though? How did you find it?
The lack of proper documentation and guidance for NuGet package-centric development is really frustrating. Let’s say I am developing an application consisting of 3 interdependent packages, updating each is really tedious..
Do you start by referencing the NuGet package? Which one gets precedence? Is it a question about versioning?´
Could this be done in a way local to the solution?
Hi Bjorn
It’s probably not documented, I stumbled across it. I think I was debugging and I looked at the “Symbols” window and saw the symbol location for my dll so copied over it and voila.
I know what you mean about lack of documentation, I’m not sure of the right way to do things either. I can only tell you the way we do it, which is to have all of our projects with packages in one “Core” solution, and they all reference each other via project references.
Our build server generates the packages and the version number. But this has the downside of any change to one package creates a new version of all packages with a corresponding version number bump. And so when you need to upgrade one package in your consuming solution you need to upgrade them all.
So the opposite way would be to keep each package in a separate solution and to reference each other via NuGet package references… with the corresponding developer friction.
I’m not sure if there’s a happy medium.