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.

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.

Answer 2

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

Answer 3

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.