Dotnet-docker: dotnet restore fails in docker build

Created on 27 Dec 2016  路  8Comments  路  Source: dotnet/dotnet-docker

Steps to reproduce the issue

  1. With dotnet SDK 1.0.0-preview4-004233, run 'dotnet new' in a temporary directory.
  2. Create Dockerfile in that same directory:
FROM microsoft/dotnet:1.1-sdk-msbuild

COPY . /app

WORKDIR /app

RUN ["dotnet", "restore"]
  1. Run docker build . from the work directory.

Expected behavior

Build should work.

Actual behavior

$ docker build .
time="2016-12-27T15:33:39-06:00" level=warning msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Sending build context to Docker daemon 4.096 kB
Step 1 : FROM microsoft/dotnet:1.1-sdk-msbuild
 ---> 88431ef47193
Step 2 : COPY . /app
 ---> aad5e4c2bce0
Removing intermediate container a349cb73debd
Step 3 : WORKDIR /app
 ---> Running in 91a16c44e245
 ---> e53613d69f35
Removing intermediate container 91a16c44e245
Step 4 : RUN dotnet restore
 ---> Running in 4fdbccd4f50f
/app/dndocker.csproj : error MSB4057: The target "Restore" does not exist in the project.
The command 'dotnet restore' returned a non-zero code: 1

Additional information (e.g. issue happens only occasionally)

This is a minimal reproducible case extracted from a more complex case. Everything was working great before I upgraded to the new msbuild/.csproj format (thanks a lot for that Microsoft... I guess cross-platform isn't your thing after all)

Output of docker version

$ docker version
time="2016-12-27T15:37:25-06:00" level=warning msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Client:
 Version:      1.13.0-rc2
 API version:  1.24
 Go version:   go1.7.3
 Git commit:   1f9b3ef
 Built:        Wed Nov 23 17:40:58 2016
 OS/Arch:      windows/amd64

Server:
 Version:             1.12.5-rc1
 API version:         1.24
 Minimum API version:
 Go version:          go1.6.4
 Git commit:          e9e3ab6
 Built:               Thu Dec 15 02:18:51 2016
 OS/Arch:             linux/amd64
 Experimental:        false

Output of docker info

$ docker info
time="2016-12-27T15:37:40-06:00" level=warning msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
Containers: 8
 Running: 0
 Paused: 0
 Stopped: 8
Images: 136
Server Version: 1.12.5-rc1
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 109
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary:
containerd version:
runc version:
init version:
Security Options:
 seccomp
Kernel Version: 4.4.39-boot2docker
Operating System: Boot2Docker 1.12.5-rc1 (TCL 7.2); HEAD : 0455ed0 - Thu Dec 15 18:01:53 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.8 MiB
Name: default
ID: 6U5E:RTSK:JG7H:3QG6:6ERM:J5GY:EMTO:N3RC:3CDX:JSJF:TFR4:2NZC
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 14
 Goroutines: 25
 System Time: 2016-12-27T21:37:42.095571238Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Most helpful comment

Hopefully there is a process in place whereby when the new versions of the preview tooling are released, the Docker images are also updated? Otherwise developers will upgrade and the build servers (and production environments) will not be able to keep up.

I think the Docker images should be considered first-class citizens for the tooling releases!

All 8 comments

The issue is that the SDK version that you are using to create the app (1.0.0-preview4-004233) is incompatible with the SDK version that's currently in the microsoft/dotnet:1.1-sdk-msbuild image (1.0.0-preview3-004056).

As a workaround, you can create an image that has 1.0.0-preview4-004233 by copying https://raw.githubusercontent.com/dotnet/dotnet-docker/master/1.1/debian/sdk/msbuild/Dockerfile to a local Dockerfile, changing 1.0.0-preview3-004056 to 1.0.0-preview4-004233, building the Dockerfile, and then using that locally-built image as the base of your Dockerfile that runs dotnet restore.

@richlander and @MichaelSimons, when do we plan to upgrade the *-sdk-msbuild images to preview4?

Hopefully there is a process in place whereby when the new versions of the preview tooling are released, the Docker images are also updated? Otherwise developers will upgrade and the build servers (and production environments) will not be able to keep up.

I think the Docker images should be considered first-class citizens for the tooling releases!

This is now fixed. dotnet:1.1-sdk-msbuild has been updated. Appologies to all. This was a mistake that we don't intend to repeat.

the error has resurfaced on 1.1!

FROM microsoft/dotnet:1.1.0-sdk-msbuild

RUN apt-get update
RUN wget -qO- https://deb.nodesource.com/setup_6.x | bash -
RUN apt-get install -y build-essential nodejs

COPY . /app

WORKDIR /app

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

EXPOSE 5000/tcp

CMD ["dotnet", "run", "--server.urls", "http://*:5000"]

@luis-echegaray, What version of the SDK do you have locally? What does your csproj look like? Curious if it works if you use the latest sdk image - 1.1.0-sdk-msbuild-rc4

@MichaelSimons Also reproduced this using the dotnet new reactredux project. Using 1.1.0-sdk-msbuild-rc4 did indeed fix the issue for me!

Also had the same issue. Using dotnet:1.1-sdk-msbuild instead of dotnet:1.1.0-sdk-msbuild fixed it.

New images were published today. Note the new scheme for image tags.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MichaelSimons picture MichaelSimons  路  7Comments

deployable picture deployable  路  8Comments

cypressious picture cypressious  路  5Comments

Neutrino-Sunset picture Neutrino-Sunset  路  4Comments

galvesribeiro picture galvesribeiro  路  7Comments