This morning involved an hour-long hair-pulling exercise involving the nuget package manager. Specifically, using it to add a reference to a package in my local repository, and having it complain about not being able to resolve a dependency.

The error message — when I finally figured out what it meant — was quite clear:

Unable to resolve 'CampaignMessages'...

The problem was that I was sure the package it couldn’t resolve was in the local repository. I checked that several times, before starting to rip out my hair. And each time I checked, I saw a folder labeled olbert.campaignsystem.messages…which is where I knew the CampaignMessages assembly was stored.

The problem was that nuget literally meant CampaignMessages, not “the package where CampaignMessages is stored”. It has no knowledge of what assembly is in what package; it just knows how to resolve packages.

This became very clear when I finally thought to open up the package’s nupkg file in the local repository. It listed several dependencies:

Olbert.CampaignSystems.CampaignDb...
CampaignMessages...

The second one of those doesn’t exist in the local repository. Which is what was causing the problem.

Interestingly, somewhere along the line I did something to the project having those dependencies, because the latest builds of the nupkg files show the correct references:

Olbert.CampaignSystems.CampaignDb...
Olbert.CampaignSystem.CampaignMessages...

Sadly, I have no idea what I was doing wrong earlier which caused the problem.

But at least I understand the problem better. My hair appreciates that.

FYI, once the correct references are generated, all you have to do is delete the old package from the local repository, add the new/correct one, and clear Visual Studio’s nuget package cache. After that, adding the package reference will work just fine.