dotnet aspnetcore docker build fails with a 145 error code

Question

I've used this tutorial to create my first docker webapi project.

I'm using windows 7 (docker toolbox).

This what I've ran:

dotnet new webapi

This is the Dockerfile:

FROM microsoft/dotnet:latest
COPY . /app
WORKDIR /app

RUN ["dotnet", "restore"]
RUN ["dotnet", "build"]

EXPOSE 5000/tcp
ENV ASPNETCORE_URLS http://*:5000

ENTRYPOINT ["dotnet", "run"]

This is how I created the image:

docker build -t mydemos:aspnetcorehelloworld .

And this is how I've created and ran the container:

docker run -d -p 8080:5000 -t mydemos:aspnetcorehelloworld

My service ran successfully as a docker container.

Then, I tried changing the Dockerfile to work on a aspnetcore base image:

FROM microsoft/dotnet:latest was changed to FROM microsoft/aspnetcore:1.0.1

The new Dockerfile looks like:

FROM microsoft/aspnetcore:1.0.1
COPY . /app
WORKDIR /app

RUN ["dotnet", "restore"]
RUN ["dotnet", "build"]

EXPOSE 5000/tcp
ENV ASPNETCORE_URLS http://*:5000

ENTRYPOINT ["dotnet", "run"]

Now, I've tried to build the new image using

docker build -t mydemos:aspnetcorehelloworld1 .

And I get an error.
This is the build log:

Sending build context to Docker daemon 636.9 kB
Step 1/8 : FROM microsoft/aspnetcore:1.0.1
 ---> 2c7bbc508bb2
Step 2/8 : COPY . /app
 ---> Using cache
 ---> 1d5b9bd908b3
Step 3/8 : WORKDIR /app
 ---> Using cache
 ---> c1d5d091d111
Step 4/8 : RUN dotnet restore
 ---> Running in 8399e21caeb2
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
The command 'dotnet restore' returned a non-zero code: 145

I went into the url, reinstalled stuff and I still get an error.
I've tried to use the dotnet cli commands in the same command line session and I succeed (dotnet restore works).

I've tried to search this error around, but couldn't really find any solution.

What am I missing here? I'm getting this 145 error on multiple occasions and tests.

Hileman

Answer 1

The image you are using contains the .NET Core runtime only, not the SDK. Try a base image from the following repository:

https://hub.docker.com/r/microsoft/aspnetcore-build/

---

Your Dockerfile has the following lines in it:

RUN ["dotnet", "restore"]
RUN ["dotnet", "build"]

Which means that the dotnet restore and dotnet build commands are running within the image you're using. As the image you are using doesn't have the SDK installed, these commands cannot be found and fail as you're seeing. The images in the repository I linked above have the SDK installed within them and so the dotnet restore and dotnet build commands can be found and executed.

The alternative to using a base image with the SDK installed would be to perform the build/publish process on your development machine and then simply copy the published output into the image. Your Dockerfile would then only need to look something along the lines of:

FROM microsoft/aspnetcore:1.0.1
WORKDIR /app
COPY ./app .
ENTRYPOINT ["dotnet", "TheNameOfYourProject.dll"]

Note that now the dotnet commands run within the image is simply the one that runs your (pre-built) DLL. This only requires the runtime, and not the SDK.

Irra

Thanks for the answer, but let me understand something. I'm trying to build a docker image based on another docker image which contains the runtime I need. I understand the build process needs the SDK, but why do I need a base image that contains the SDK? – Hileman

@AmirPopovich I've added some more detail into the answer, let me know if you have any other questions. – Irra

Great explanation!!! Thank you very much. Last questions: Is there a smaller image that only contains the runtime and the SDK? Is there any way I can add 2 FROM commands in my docker file? – Hileman

@AmirPopovich Not as far as I'm aware, the SDK is a little hefty unfortunately. Codifying your build process into the Dockerfile can certainly pay dividends as time goes on though, you'll have to work out if the cost is worth it in your circumstances. There's no way to derive from two images with multiple FROM commands, however you can chain images (Dockerfile A is derived FROM Dockerfile B, Dockerfile B is derived FROM Dockerfile C - think of it like layers of an onion.) – Irra

@Irra I am facings similar issue #60898687 – Marinamarinade

Answer 2

In my case was an stupid error, but maybe can help someone. I changed the project name and this broked the docker compose. So, the folder of the web app, the project (it is the .csproj file) and the DLL to run with dotnet should have the same name in my case, because I am using one variable in the dockerfile that assumes that. In summary review carefully the names we are using for each thing.

Regular

This was my problem too, its case sensitive, so the names should be equal in case also. – Hereunto

Answer 3

I received this error because of a difference between the Dockerfile and docker-compose.yml.

Dockerfile (original):

FROM microsoft/dotnet:2.2-aspnetcore-runtime AS base
WORKDIR /app
...

I changed the Dockerfile to move files to nginx's default directory...

Dockerfile (change):

FROM microsoft/dotnet:2.2-aspnetcore-runtime AS base
WORKDIR /usr/share/nginx/html
...

But the docker-compose.yml referenced the old folder...

docker-compose.yml (original):

services:
  web:
    working_dir: /app

To fix it, just update the working_dir to point to the new directory...

docker-compose.yml (fix):

services:
  web:
    working_dir: /usr/share/nginx/html

Experimentalism

Answer 4

In my case I renamed the assembly name and that was creating failure. I noticed on the last line of Dcokerfile

ENTRYPOINT ["dotnet", "assembly_name.dll"]

assembly_name was not correct.

Magically

Answer 5

I Solved my problem by referencing the sdk instead of the aspnet on the docker compose

Use this : FROM mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim AS publish

instead of this: FROM mcr.microsoft.com/dotnet/aspnet:6.0-bullseye-slim AS publish

Weems

Answer 6

Still found myself a bit stupid after figuring out that after 60 minutes of investigation getting this error, rebooting my computer, flushing images from Docker Client, cleaning my solution, investingating naming within docker files... all that was because my solution was set to "Release" instead of "Debug", which prevents it from doing its job properly.

If ever that can help someone in the future...

Gerenuk