error NETSDK1064: Package Humanizer.Core, version 2.14.1 was not found. It might have been deleted since NuGet restore. in a Docker build means dotnet publish --no-restore ran in a stage that has the restore results in obj but not the downloaded packages. Restore and publish in the same stage.

In the reproduction, restore ran in one stage and the /src folder was copied into a second SDK stage for the publish. Moving both steps into one stage fixed it.

The error

#14 [build 5/5] RUN dotnet publish -c Release -o /out --no-restore
#14 0.832 /usr/share/dotnet/sdk/10.0.302/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1064: Package Humanizer.Core, version 2.14.1 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions. [/src/ClinicApi.csproj]
#14 ERROR: process "/bin/sh -c dotnet publish -c Release -o /out --no-restore" did not complete successfully: exit code: 1
...
ERROR: failed to build: failed to solve: process "/bin/sh -c dotnet publish -c Release -o /out --no-restore" did not complete successfully: exit code: 1

Why it happens

The failing Dockerfile looked tidy: 

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS restore
WORKDIR /src
COPY ClinicApi.csproj .
RUN dotnet restore

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY --from=restore /src .
COPY Program.cs .
RUN dotnet publish -c Release -o /out --no-restore
...

It was built with docker build --progress=plain --no-cache -t fix10-dn-pkg .. In the restore stage, dotnet restore left project.assets.json in /src/obj and the package in /root/.nuget/packages, outside /src. The build stage copied only /src, and its --no-restore publish stopped with NETSDK1064 naming that package. The project used one package, Humanizer.Core 2.14.1, and that is the one the message names. Listing the restore stage shows the split: 

PS> docker run --rm --name fix10-dn-pkg3 fix10-dn-pkgrestore ls /root/.nuget/packages /src /src/obj
/root/.nuget/packages:
humanizer.core

/src:
ClinicApi.csproj
obj

/src/obj:
ClinicApi.csproj.nuget.dgspec.json
ClinicApi.csproj.nuget.g.props
ClinicApi.csproj.nuget.g.targets
project.assets.json
project.nuget.cache

The message offers two guesses: a package deleted after the restore, or a restore cut short by maximum path length. Neither applied here. Nothing was deleted and the paths were short; the package simply lived in the file system of another stage, which the publish could not see.

The fix

FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ClinicApi.csproj .
RUN dotnet restore
COPY Program.cs .
RUN dotnet publish -c Release -o /out --no-restore

FROM mcr.microsoft.com/dotnet/runtime:10.0
WORKDIR /app
COPY --from=build /out .
ENTRYPOINT ["dotnet", "ClinicApi.dll"]
PS> docker run --rm --name fix10-dn-pkg2 fix10-dn-pkgfix
Next visit for Maria Garcia: 3 days

Restore and publish now share one stage, so the packages from the restore layer are still there for the publish, and the image ran. The project file is still copied on its own before the source, as in the failing version; only the stage boundary between the two steps is gone.

How it was reproduced

A console app from dotnet new console -n ClinicApi with one package reference, Humanizer.Core 2.14.1, built with docker build --progress=plain --no-cache from the three-stage Dockerfile above (the third stage is the runtime image) on mcr.microsoft.com/dotnet/sdk:10.0 (SDK 10.0.302), Docker engine 29.9.3 on Windows 11. A publish with -r linux-musl-x64 --no-restore after a restore without a runtime identifier, in one stage, was also tried; it did not give NETSDK1064 but NETSDK1047 (Assets file '/src/obj/project.assets.json' doesn't have a target for 'net10.0/linux-musl-x64').

Frequently asked

What does NETSDK1064 mean in a Docker build?
The project's obj folder says a package was restored, but the package is not in the NuGet folder of the stage that builds. In the test that happened because restore and publish ran in different stages.
Can I run dotnet restore in a separate Docker stage?
Not with publish --no-restore in the next stage and only /src copied across. The downloaded packages stayed in the first stage and the publish failed with NETSDK1064.
Does a different runtime identifier cause NETSDK1064?
Not in this test. A restore without a runtime identifier followed by publish -r linux-musl-x64 --no-restore gave NETSDK1047, an assets file without a target for net10.0/linux-musl-x64.

A restore made for one runtime identifier and a build for another gives a different error, NETSDK1047. More decoded errors in the Fixes category.