search

dotnet / dotnet-docker

Docker images for .NET and the .NET Tools.
https://hub.docker.com/_/microsoft-dotnet
MIT License
4.46k stars 1.94k forks source link

Mismatch in asp.net core 3 runtime version in docker #1359

Closed chrisbecke closed 5 years ago

chrisbecke commented 5 years ago

Steps to reproduce the issue

  1. Using Visual Studio for Mac 8.3.1 build 18 create a new ASP.NET Core webapi project
  2. Add Docker support
  3. Run

Expected behavior

The project should build and run successfully using docker-compose.

Actual behavior

The WebAPI fails to start in docker as the selected image does not have a compatible framework.

This error appears in the application output.

Starting: "docker" exec -i c1a68dba469c /bin/sh -c "ID=.; if [ -e /etc/os-release ]; then . /etc/os-release; fi; if [ $ID = alpine ] && [ -e /remote_debugger/linux-musl-x64/vsdbg ]; then VSDBGPATH=/remote_debugger/linux-musl-x64; else VSDBGPATH=/remote_debugger; fi; $VSDBGPATH/vsdbg --interpreter=vscode --interpreter=vscode"
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      3.0.0-preview9.19424.4 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The .NET Core frameworks can be found at:
  - https://aka.ms/dotnet-download
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[61] dotnet' has exited with code 150 (0x96).

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

dotnet --version run on my PC yields 3.0.100, and running the project without the docker-compose works perfectly. Examining the generated runtimeconfig.json confirms that Visual Studio expects AsoNetCore.App 3.0.0 to be available:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.AspNetCore.App",
      "version": "3.0.0"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

and the generated Dockerfile is using the latest image descriptions:

FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY webapi/webapi.csproj webapi/
RUN dotnet restore "webapi/webapi.csproj"
COPY . .
WORKDIR "/src/webapi"
RUN dotnet build "webapi.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "webapi.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "webapi.dll"]

Output of docker version

Client: Docker Engine - Community
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        6a30dfc
 Built:             Thu Aug 29 05:26:49 2019
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       6a30dfc
  Built:            Thu Aug 29 05:32:21 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          v1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683```

## Output of `docker info`

Client: Debug Mode: false

Server: Containers: 48 Running: 2 Paused: 0 Stopped: 46 Images: 177 Server Version: 19.03.2 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: cgroupfs Plugins: Volume: local Network: bridge host ipvlan macvlan null overlay Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog Swarm: inactive Runtimes: runc Default Runtime: runc Init Binary: docker-init containerd version: 894b81a4b802e4eb2a91d1ce216b8817763c29fb runc version: 425e105d5a03fabd737a126ad93d62a9eeede87f init version: fec3683 Security Options: seccomp Profile: default Kernel Version: 4.9.184-linuxkit Operating System: Docker Desktop OSType: linux Architecture: x86_64 CPUs: 2 Total Memory: 1.952GiB Name: docker-desktop ID: AUTG:FMMK:AQ7K:GPPC:PW3D:QDGC:YDYL:LANZ:4H2B:3ANY:KNTS:M35I Docker Root Dir: /var/lib/docker Debug Mode: true File Descriptors: 36 Goroutines: 51 System Time: 2019-10-01T05:41:17.640626941Z EventsListeners: 2 HTTP Proxy: gateway.docker.internal:3128 HTTPS Proxy: gateway.docker.internal:3129 Registry: https://index.docker.io/v1/ Labels: Experimental: true Insecure Registries: der2377:5000 127.0.0.0/8 Live Restore Enabled: false Product License: Community Engine

cskwrd commented 5 years ago

To add to this. I am using VS 2019. I have added linux container support to my newly created MVC app. Previously I had both VS 2019 and the preview installed, as well as, SDK's from 2.1 to 3.0-rc1. I had also used a few nightlies around the time of preview 8. It appears to me that all have been uninstalled and then I reinstalled VS 2019 and dotnet core 3.0.

My dockerfile only differs by project name.

When I try to run my project from docker the error I get is similar except for 3.0.0-preview7.19365.7 at [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]. I don't know much about the intricacies docker, so I have no (good) guesses as to why a different framework is detected for me. Maybe some load balancing when pulling images from mcr.microsoft.com, or some sort of image caching on local machine?

Ultimately, I would like my app to run in alpine containers. While trying to modify my docker file to run alpine containers I discovered a work around for the time being.

Instead of using the *buster* tags, I was able to run my app using the tag: latest

@chrisbecke see above for my work around.

chrisbecke commented 5 years ago

I tried searching to see where things like "buster" etc were documented: I had figured, given the lack of other reports, that this is probably some kind of cdn cache issue and thought to try a different tag. But got distracted by the futile search. I'll give that another go.

mthalman commented 5 years ago

Have you made sure to run docker pull prior to building your Docker image (e.g. docker pull mcr.microsoft.com/dotnet/core/sdk:3.0-buster). This will ensure you're using the latest version of that tag.

cskwrd commented 5 years ago

@mthalman Personally, I have only used Visual Studio's docker integration. By this I mean, I have a dockerfile (generated by VS), and click the play button (or press F5). It appears as though a new image is pulled, but I am not sure how I would know for sure.

mthalman commented 5 years ago

@cskwrd - You can know for sure by running the docker pull command. It'll either pull down a new version or no-op if you've got the latest.

cskwrd commented 5 years ago

There is not a way to do this from VS? Do I (or a dev working on my project) need to just know that this step must be preformed from time to time? Is that part of the normal docker workflow? Is there a change that I can make to my project or dockerfile to disable caching?

mthalman commented 5 years ago

@cskwrd - I don't know. This repo is for issues with the .NET Docker images, not the VS tools. I'm just trying to gather information so we can diagnose where the issue is.

cskwrd commented 5 years ago

Ah okay. I will check tonight and report back. Thanks!

cskwrd commented 5 years ago

@mthalman I believe my issue is that the image is cached. I added --pull as an arg to docker build, and I am able to now run my app in an alpine container.

From a docker(file) point of view, once a new version of dotnet is released I would need to use --pull to update my local cache of the latest tag correct?

mthalman commented 5 years ago

From a docker(file) point of view, once a new version of dotnet is released I would need to use --pull to update my local cache of the latest tag correct?

Yes, that's true for any tag.

mthalman commented 5 years ago

@chrisbecke - What about you? Have you made sure to pull the latest version of the tag?

mthalman commented 5 years ago

@bwateratmsft - Does the VS Docker Tools have any logic to support the automatic pulling of the latest tag when building? What's the story for the tools here?

bwateratmsft commented 5 years ago

@mthalman We're adding some in 16.4 for that. More here: https://github.com/microsoft/DockerTools/issues/214

It'll happen on project open, though. Our default will be to pull all .NET Core base images. You can choose none, .NET Core, or all (.NET Core + .NET Framework). We didn't do .NET Framework by default because the images are so huge it makes for a bad UX.

chrisbecke commented 5 years ago

Yep - docker pull got a fresher version of the runtime image :-

$ docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim
3.0-buster-slim: Pulling from dotnet/core/aspnet
b8f262c62ec6: Pull complete 
c1bb02c48b82: Pull complete 
aac1cb0f3412: Pull complete 
9e34bee673bb: Pull complete 
e1c733f95268: Pull complete 
Digest: sha256:b0fd451ed5dcd9c86a5c5364b478ebfb411beada0740369127fa53bca365650f
Status: Downloaded newer image for mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim

I still had to clean the project - which I wasn't expecting - but thereafter it ran.