asp.net-core .net-core nuget nuget-package-restore dotnet-cli

dotnet restore fails with NU1101 for private Github package in Docker container, but works on my local machine

I have published a NuGet package (BuildingBlocks) to Github Packages. I use a nuget.config file to specify the nuget sources for my project, along with the credentials for my package (credentials replaced with placeholders on purpose):

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
    <add key="github" value="https://nuget.pkg.github.com/<username>/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <github>
      <add key="Username" value="<username>" />
      <add key="ClearTextPassword" value="<password>" />
    </github>
  </packageSourceCredentials>
</configuration>

When I run dotnet restore locally on my Fedora machine it works fine. But when I attempt to restore packages in a Docker container deriving from the mcr.microsoft.com/dotnet/sdk image, the restore fails with the following errors:

  Determining projects to restore...
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.Annotations. No packages exist with this id in source(s): github, nuget
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.Localization. No packages exist with this id in source(s): github, nuget
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.IoC. No packages exist with this id in source(s): github, nuget
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.Nullability. No packages exist with this id in source(s): github, nuget
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.Domain. No packages exist with this id in source(s): github, nuget
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.Commands. No packages exist with this id in source(s): github, nuget
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.Option. No packages exist with this id in source(s): github, nuget
/app/src/DocumentService.Application/DocumentService.Application.csproj : error NU1101: Unable to find package BuildingBlocks.Queries. No packages exist with this id in source(s): github, nuget

My BuildingBlocks package does not have a namespace such as Annotations and Localization, so I don't know why the dotnet CLI writes these to the output. Does anyone have an idea on how to solve this, or why it occurs?

Solution

My assumption is that your BuildingBlocks package is defined in your GitHub package feed. If so, then it's conflicting with an already existing package at https://www.nuget.org/packages/BuildingBlocks. Unfortunately, NuGet doesn't have deterministic behavior when resolving packages and multiple feeds are specified in NuGet.config. The reason for the actual errors is that the BuildingBlocks package in nuget.org has dependencies on those other packages listed in the errors which haven't been published to nuget.org.

The easiest way to resolve this is to rename your package to not conflict with a package name that exists in nuget.org.

The other option is to create a single NuGet feed with upstream sources that allow you to deterministically control the feed source of packages. I don't know if this can be done in GitHub but I know it can be done with Azure DevOps: Upstream sources.

Benefits of upstream sources

Upstream sources enable you to manage all of your product's dependencies in a single feed. We recommend publishing all of the packages for a given product to that product's feed, and managing its dependencies from remote feeds in the same feed, via upstream sources. This setup has a few benefits:

Simplicity: your NuGet.config, .npmrc, or settings.xml contains exactly one feed (your feed).

Determinism: your feed resolves package requests in order, so rebuilding the same codebase at the same commit or changeset uses the same set of packages.

Provenance: your feed knows the provenance of packages it saved via upstream sources, so you can verify that you're using the original package, not a custom, or malicious copy published to your feed.

Peace of mind: packages used via upstream sources are guaranteed to be saved in the feed on first use. If the upstream source is disabled/removed or the remote feed goes down or deletes a package you depend on, you can continue to develop and build.