Search code examples
c#namespacesnuget

Compiler claims NuGet package missing namespace, decompiler disagrees?

I have a project (call it Fancy.Common.Types) containing some commonly used enums and marker types, which is ProjectReference'd by a lot of projects in a solution.

However, I wish to release one of these projects (call it Fancy.Service.Client) as a NuGet package, so I created a NuGet package of Fancy.Common.Types, released to our company feed.

I have thise NuGet package downloaded. Opening it with JetBrains' dotPeek decompiler, I can see it contains all the correct enum definitions and such; nothing seems to be amiss.

When I replace the ProjectReference to Fancy.Common.Types in Fancy.Service.Client.csproj with a PackageReference to the new NuGet package, I get the following error:

The type or namespace 'Common' does not exist in the namespace 'Fancy' (are you missing an assembly reference?)

Google is, predictably, proving unhelpful. I am nearing the point where I give up software development and go live as a hermit in the mountains, what on earth am I doing wrong?

I have tried:

  • Cleaning the solution
  • Building in a CI pipeline
  • Ensuring the frameworks are the same for Fancy.Common.Types and Fancy.Service.Client (they are both net6.0.)
  • Checking for spelling mistakes (there are none, I converted the project from using a project reference to a package reference of the same project, the names haven't changed.)

ETA: @PMF suggested that I might have ProjectReference dependencies in Fancy.Service.Client which in turn have ProjectReferences directly to Fancy.Common.Types. This does turn out to be the case, but does not seem to be the cause of the issue.

There is another project Fancy.Messages which has no ProjectReference dependencies aside from Fancy.Common.Types and if I change that to a PackageReference, the error persists there.

ETA2: Spent sixty legal minutes chasing down dependencies, and finally found it, it was as @PMF suggested, a dependency conflict.

Solution

  • The root of the issue was that somewhere along in the deep tree of dependencies there was a ProjectReference to the Fancy.Common.Types project. Once I eliminated that, it compiled.

    Just another 'gotcha' when working with dotnet packages: there is no sanity checks for conflicts like this.

    A less generous individual than myself might deem this a glaring design flaw, that probably costs the average dotnet developer a hundred hours of lost productivity over their career.