This was a bloody one, so here is an advice:
Pay extra attention when you use NuGet package manager and update a dependency that is used in more than one of your projects!
So, why is it broken? Let me explain…
This is our solution structure:
Both highlighted projects use the NuGet package “RavenDB.Embedded”. Recently we had an issue with a customer that was fixed in build 2024. So, I used the package manager window to update to RavenDB build 2025:
I then pushed the commit to our repository and TeamCity started the psake task to build and deploy the package. This worked great – the issue was fixed!
Since then (about 2 weeks) we shipped about 30 new builds of our software and had no problems. However, the issue re-appeared today and it was exactly the same problem that we had back then.
After some headaches I found out that for some reason we were deploying RavenDB version 2005 again, although the NuGet package clearly was on build 2025!
I have to admit – it took me some time to figure this… the problem was that NuGet update works per project and not for the whole solution! So, while one project was on version 2025, the other still was on 2005:
I can’t get my head around why I would want to update only one project but leave the other untouched. This makes absolutely no sense to me and apparently it causes some issues with msbuild as well (was shipping the newer version before but then returned for no reason).
I hope that this weird behavior will be fixed with an upcoming NuGet version (this was 2.0), but until then we must remember to update NuGet packages in every project of the solution!
Have you used the update on the solution or on the project level?
I updated nuget packages alot from our internal repository and I had never such an issue.
The only bugs I can remember are the pain of checking in dll’s (solved with the reload on build feature) and one project that refused to use the dll’s from the package-path but reused the ones from it’s own bin directory after each update.
That was easily solved by deleting the bin path, cleaning up all traces of nuget in this project and reinstalling the package again.
Yes, the bug you’re mentioning is another one that I’ve encountered a few times and solved exactly the same way you did. However, regarding this bug (I’m not even sure if it is actually a bug or just the expected behavior of some programmer’s mind) – yes, I did update from clicking right on the project. I know it would not have been the case if I clicked on the solution itself, however, I don’t think that there should be a difference. It’s just not the expected behavior and there’s also no dialog box warning me like “hey, you’re just updating the package in this one project, but there are others as well, would you like to…” – you get the idea.
Hmm… I don’t know.
In some cases there might be a reason to use different versions.
On example I can think of is when functionality get’s renamed or changed in some way – you could call that bad API design but I think it’s just reality.
I had such a issue with updating the RX-package of an older application (using the beta … so no blame here) – FromEvent(?) is now called FromEventPattern (or something similar) but the other one is still around but has another signature so all hell broke lose …
And if you think of how the packages are put to disk (each version in it’s own folder), than this *IS* the expected behavior of only updating one part of the solution – at least for me
Yes, I can think of such edge cases as well – we had to do that once because two different third party libraries were both using different versions of Json.NET and we couln’t workaround it by using assembly redirects… Yes, that’s definitely possible, but should this be the default behavior? Uhm, no, definitely not. Its ok to have a way to accomplish this when needed, but I’ll also bet that 9 out 10 developers would expect the whole solution to be updated. Just in case I had asked you yesterday before you read the post, I’m not sure if you had guessed the same…, right?