Closed Arclight3 closed 1 month ago
@Arclight3 the error your seeing is due to dotnet restore
in your container failing; most of the error message appears to be an issue in our error checking logic that's trying to diagnose why the build failed (it looks like we have an error checking path that has an issue when Docker is configured with a hyper-v backend instead of WSL2), but the stack trace is happening after the build has already failed.
Possible issues could include either an issue in your nuget.config (such as a source that references a local file path not present in your container image) or networking issues on the Docker Hyper-V backend. There should be additional output logs above the failed dotnet restore
command that may include actual error output from the dotnet restore
build step; could you share that to help troubleshoot?
Thanks @danegsta for the reply.
I didn't find any relevant logs above the dotnet restore
, but I attached below multiple VS and CLI build outputs.
I cleared the output console before build and copied the full output after the build.
Hopefully they will help 😄
You can also see the scenario that produced each output.
# Build stage/image
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
#FROM mcr.microsoft.com/dotnet/sdk:7.0-jammy AS build
WORKDIR /source COPY ["nuget.config", "."] COPY ["MyApp/MyApp.Api.csproj", "MyApp.Api/"]
ENV NUGET_XMLDOC_MODE none RUN dotnet restore "MyApp.Api/MyApp.Api.csproj" --configfile nuget.config
COPY [".", "."] WORKDIR "/source/MyApp.Api" ARG buildnumber RUN dotnet publish "MyApp.Api.csproj" --no-restore -c Release -p:Version=$buildnumber -o /app
FROM mcr.microsoft.com/dotnet/aspnet:7.0 as final
WORKDIR /app COPY --from=build /app .
EXPOSE 8080 ENV ASPNETCORE_URLS=http://*:8080
ENTRYPOINT ["./MyApp.Api"]
All combinations of images presented in the Dockerfile above fail with these errors:
[vs_log_1.txt](https://github.com/dotnet/dotnet-docker/files/13612780/vs_log_1.txt)
[cli_log_1.txt](https://github.com/dotnet/dotnet-docker/files/13612785/cli_log_1.txt)
2. Building the docker layers in this order (base -> build -> final) with the following images works from VS (but still fails on CLI). The commented FROM statements shows what other combinations I tried (4 total):
```Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:7.0 AS base
#FROM mcr.microsoft.com/dotnet/aspnet:7.0-jammy AS base
WORKDIR /app
EXPOSE 8080
ENV ASPNETCORE_URLS=http://*:8080
# Build stage/image
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
#FROM mcr.microsoft.com/dotnet/sdk:7.0-jammy AS build
WORKDIR /source
COPY ["nuget.config", "."]
COPY ["MyApp.Api/MyApp.Api.csproj", "MyApp.Api/"]
ENV NUGET_XMLDOC_MODE none
RUN dotnet restore "MyApp.Api/MyApp.Api.csproj" --configfile nuget.config
COPY [".", "."]
WORKDIR "/source/MyApp.Api"
ARG buildnumber
RUN dotnet publish "MyApp.Api.csproj" --no-restore -c Release -p:Version=$buildnumber -o /app
# Final stage/image
FROM base AS final
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["./MyApp.Api"]
FROM mcr.microsoft.com/dotnet/aspnet:7.0-jammy-chiseled AS base
WORKDIR /app
EXPOSE 8080
ENV ASPNETCORE_URLS=http://*:8080
FROM mcr.microsoft.com/dotnet/sdk:7.0 AS build
WORKDIR /source COPY ["nuget.config", "."] COPY ["MyApp.Api/MyApp.Api.csproj", "MyApp.Api/"]
ENV NUGET_XMLDOC_MODE none RUN dotnet restore "MyApp.Api/MyApp.Api.csproj" --configfile nuget.config
COPY [".", "."] WORKDIR "/source/MyApp.Api" ARG buildnumber RUN dotnet publish "MyApp.Api.csproj" --no-restore -c Release -p:Version=$buildnumber -o /app
FROM base AS final WORKDIR /app COPY --from=build /app .
ENTRYPOINT ["./MyApp.Api"]
[vs_log_3.txt](https://github.com/dotnet/dotnet-docker/files/13612879/vs_log_3.txt)
[cli_log_3.txt](https://github.com/dotnet/dotnet-docker/files/13612913/cli_log_3.txt)
**Conclusions**:
- The CLI build **fails** always
- The VS build **fails** always with layers order (build -> final)
- The VS build **works** with layers order (base -> build -> final) - when not using jammy-chiseled
- The VS build **fails** with layers order (base -> build -> final) - when using jammy-chiseled
I did another test with a "clean" application, with no build arguments or private nuget feeds.
1.A. I built a new Web API with Docker support using the VS template. 1.B. I ran it in Docker from VS (without any changes) and it worked.
2.A. I updated the Dockerfile as seen below to use the aspnet:8.0
or aspnet:8.0-jammy
base image.
2.B. I ran it in Docker from VS and it worked.
3.A. I updated the Dockerfile as seen below to use the aspnet:8.0-jammy-chiseled
base image.
3.B. I ran it in Docker from VS and it failed.
csproj:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.19.5" />
</ItemGroup>
</Project>
Dockerfile:
#FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
#FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy AS base
FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled AS base
WORKDIR /app
EXPOSE 8080
ENV ASPNETCORE_URLS=http://*:8080
# Build stage/image
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /source
COPY ["MyApp2.Api/MyApp2.Api.csproj", "MyApp2.Api/"]
RUN dotnet restore "MyApp2.Api/MyApp2.Api.csproj"
COPY [".", "."]
WORKDIR "/source/MyApp2.Api"
RUN dotnet publish "MyApp2.Api.csproj" --no-restore -c Release -o /app
# Final stage/image
FROM base AS final
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["./MyApp2.Api"]
The jammy-chiseled
failed build logs: new_app_vs_log_1.txt
For the scenarios with a base stage in addition to build and final (without chiseled), the reason that's working in VS, but not the CLI, is that VS by default runs the application in what we call "fast mode", which only builds and runs the first base
stage, before building and restoring the application with a normal local build and volume mounting it into the container. This means that any container specific build/restore issues won't show up during a default debug launch in VS.
You can read about some of the "fast mode" optimizations here: https://learn.microsoft.com/en-us/visualstudio/containers/container-build?view=vs-2022#debugging
A few possible things to investigate:
I notice you have a ARG buildnumber
defined in your Dockerfiles add referenced in your dotnet publish
command, but I don't see in your .csproj a DockerfileBuildArguments
property that would ensure a value is provided for that argument (see: https://learn.microsoft.com/en-us/visualstudio/containers/container-msbuild-properties?view=vs-2022). That may be causing your dotnet publish
command to fail in the container.
It seems that, with the logs you provided, your builds are failing once they try to start copying files into the image build (the last successful commands executed are both WORKDIR
commands, while I don't see the following COPY
commands being executed). Based on the original error message you provided, you most likely have your Docker engine configured to use Hyper-V, which is much more sensitive to drive sharing and folder permissions than the newer WSL2 based engine. I'd highly recommend trying to switch Docker to use WSL2 (From Docker Desktop: Settings > General > Use the WSL 2 based engine
) and see if that resolves the build issues you're running into.
In general, I'd recommend starting with the default Dockerfile produced by VS when right clicking on a project and selecting Add > Docker Support...
and customizing the image tags, rather than working with a custom (or heavily customized) Dockerfile. That will give you what we've found to be a known good starting place for both VS and the CLI. I'd like to get you in a place where you're able to build and run in both VS and the CLI with a non-chiseled image, then we can look at switching you to chiseled in a way that'll keep everything working.
There are some known issues in VS for supporting chiseled images for debugging without some workarounds, but nothing that would prevent us from building a chiseled image, once we get your builds unblocked, I can go over the workarounds for running/debugging chiseled images in VS.
Interersting stuff about the fast mode. Thanks for the resources. I`ll read more about it.
I switched to WSL2, and didn't help.
I took your advice to start from the default Dockerfile produced by VS. I created a new Web API with Docker support. It produced this Dockerfile:
#See https://aka.ms/customizecontainer to learn how to customize your debug container and how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base USER app WORKDIR /app EXPOSE 8080
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build ARG BUILD_CONFIGURATION=Release WORKDIR /src COPY ["MyApp3.Api/MyApp3.Api.csproj", "MyApp3.Api/"] RUN dotnet restore "./MyApp3.Api/./MyApp3.Api.csproj" COPY . . WORKDIR "/src/MyApp3.Api" RUN dotnet build "./MyApp3.Api.csproj" -c $BUILD_CONFIGURATION -o /app/build
FROM build AS publish ARG BUILD_CONFIGURATION=Release RUN dotnet publish "./MyApp3.Api.csproj" -c $BUILD_CONFIGURATION -o /app/publish /p:UseAppHost=false
FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "MyApp3.Api.dll"]
This one works.
Then, all I did was to change the base image to ```mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled``` and it stopped working.
I get this error:
```log
Build started at 11:16 AM...
1>------ Build started: Project: MyApp3.Api, Configuration: Debug Any CPU ------
1>docker exec -i b12f551338478a3e6c1171eaca3431e258f9cc82ed0c343d2e2cfcb3956138d8 /bin/sh -c "if PID=$(pidof dotnet); then kill $PID; fi"
1>C:\Development\MyApp3\MyApp3.Api\MyApp3.Api.csproj : warning NU1803: You are running the 'restore' operation with an 'HTTP' source, 'http://my-private-artifactory/api/nuget/NuGet-virtual'. Non-HTTPS access will be removed in a future version. Consider migrating to an 'HTTPS' source.
1>Skipping analyzers to speed up the build. You can execute 'Build' or 'Rebuild' command to run analyzers.
1>MyApp3.Api -> C:\Development\MyApp3\MyApp3.Api\bin\Debug\net8.0\MyApp3.Api.dll
1>docker build -f "C:\Development\MyApp3\MyApp3.Api\Dockerfile" --force-rm -t myapp3api:dev --target base --build-arg "BUILD_CONFIGURATION=Debug" --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=MyApp3.Api" "C:\Development\MyApp3"
1>2023/12/12 11:16:26 http2: server: error reading preface from client //./pipe/docker_engine: file has already been closed
1>#0 building with "default" instance using docker driver
1>
1>#1 [internal] load .dockerignore
1>#1 transferring context: 464B done
1>#1 DONE 0.0s
1>
1>#2 [internal] load build definition from Dockerfile
1>#2 transferring dockerfile: 908B done
1>#2 DONE 0.0s
1>
1>#3 [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled
1>#3 DONE 0.0s
1>
1>#4 [base 1/2] FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled
1>#4 CACHED
1>
1>#5 [base 2/2] WORKDIR /app
1>#5 DONE 0.0s
1>
1>#6 exporting to image
1>#6 exporting layers 0.0s done
1>#6 writing image sha256:8b209146c7ce50e0560f19d8587a3db8d96155ef5c577d11ab83f62c03af0d74 done
1>#6 naming to docker.io/library/myapp3api:dev done
1>#6 DONE 0.0s
1>
1>What's Next?
1> View a summary of image vulnerabilities and recommendations → docker scout quickview
1>docker rm -f b12f551338478a3e6c1171eaca3431e258f9cc82ed0c343d2e2cfcb3956138d8
1>b12f551338478a3e6c1171eaca3431e258f9cc82ed0c343d2e2cfcb3956138d8
1>docker run -dt -v "C:\Users\MyUser\vsdbg\vs2017u5:/remote_debugger:rw" -v "C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Sdks\Microsoft.Docker.Sdk\tools\TokenService.Proxy\linux-x64\net6.0:/TokenService.Proxy:ro" -v "C:\Program Files\Microsoft Visual Studio\2022\Professional\MSBuild\Sdks\Microsoft.Docker.Sdk\tools\HotReloadProxy\linux-x64\net6.0:/HotReloadProxy:ro" -v "C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\HotReload:/HotReloadAgent:ro" -v "C:\Development\MyApp3\MyApp3.Api:/app" -v "C:\Development\MyApp3:/src/" -v "C:\Users\MyUser\.nuget\packages\:/.nuget/fallbackpackages" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "NUGET_PACKAGES=/.nuget/fallbackpackages" -e "NUGET_FALLBACK_PACKAGES=/.nuget/fallbackpackages" -P --name MyApp3.Api --entrypoint tail myapp3api:dev -f /dev/null
1>80daff4f3cddd4bfbc28add98b733bc8985968283004995161e09afdf4c95fcd
1>docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "tail": executable file not found in $PATH: unknown.
1>docker rm -f 80daff4f3cddd4bfbc28add98b733bc8985968283004995161e09afdf4c95fcd
1>80daff4f3cddd4bfbc28add98b733bc8985968283004995161e09afdf4c95fcd
1>C:\Users\MyUser\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.19.5\build\Container.targets(215,5): error CTC1015: Docker command failed with exit code 127.
1>C:\Users\MyUser\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.19.5\build\Container.targets(215,5): error CTC1015: docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "tail": executable file not found in $PATH: unknown.
1>C:\Users\MyUser\.nuget\packages\microsoft.visualstudio.azure.containers.tools.targets\1.19.5\build\Container.targets(215,5): error CTC1015: If the error persists, try restarting Docker Desktop.
1>Done building project "MyApp3.Api.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 11:16 AM and took 03.659 seconds ==========
I think the relevant part of the error is: exec: "tail": executable file not found in $PATH: unknown.
, but I have no idea where it needs tail.. You think it's related to one of the dotnet commands?
I did some research and found this page: "https://learn.microsoft.com/en-us/visualstudio/containers/container-build?view=vs-2022#container-entry-point" saying that VS is using tail
to run Linux containers in debug mode.
This means running jammy-chiseled
based images in debug mode is not currently possible in Visual Studio, right?
Based on the information from the docs mentioned above, I tried to run the new app from VS in Docker, in Release mode (thinking the debugger won't be attached) and tail won't be used. But it fails (with a different error):
Build started at 1:19 PM...
1>------ Build started: Project: MyApp3.Api, Configuration: Release Any CPU ------
1>docker exec -i cc0bbed9c8380b6b9ca04ea0c64116c0a98136d6f98ef738820090f1d7b8880b /bin/sh -c "if PID=$(pidof dotnet); then kill $PID; fi"
1>C:\Development\MyApp3\MyApp3.Api\MyApp3.Api.csproj : warning NU1803: You are running the 'restore' operation with an 'HTTP' source, 'http://my-private-artifactory/api/nuget/NuGet-virtual'. Non-HTTPS access will be removed in a future version. Consider migrating to an 'HTTPS' source.
1>Skipping analyzers to speed up the build. You can execute 'Build' or 'Rebuild' command to run analyzers.
1>MyApp3.Api -> C:\Development\MyApp3\MyApp3.Api\bin\Release\net8.0\MyApp3.Api.dll
1>docker build -f "C:\Development\MyApp3\MyApp3.Api\Dockerfile" --force-rm -t myapp3api --build-arg "BUILD_CONFIGURATION=Release" --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=MyApp3.Api" "C:\Development\MyApp3"
1>2023/12/12 13:19:16 http2: server: error reading preface from client //./pipe/docker_engine: file has already been closed
1>#0 building with "default" instance using docker driver
1>
1>#1 [internal] load .dockerignore
1>#1 transferring context: 464B done
1>#1 DONE 0.0s
1>
1>#2 [internal] load build definition from Dockerfile
1>#2 transferring dockerfile: 1.15kB done
1>#2 DONE 0.0s
1>
1>#3 [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled
1>#3 DONE 0.0s
1>
1>#4 [internal] load metadata for mcr.microsoft.com/dotnet/sdk:8.0
1>#4 DONE 0.6s
1>
1>#5 [base 1/2] FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled
1>#5 DONE 0.0s
1>
1>#6 [base 2/2] WORKDIR /app
1>#6 CACHED
1>
1>#7 [final 1/2] WORKDIR /app
1>#7 CACHED
1>
1>#8 [internal] load build context
1>#8 transferring context: 203.60kB 0.0s done
1>#8 CANCELED
1>
1>#9 [build 1/7] FROM mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b
1>#9 resolve mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 0.0s done
1>#9 sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 1.08kB / 1.08kB done
1>#9 sha256:b1192f7b91d2cc1d81d865ff7b0f47b34ed1ca06fbac655d85f59761a5074e40 2.22kB / 2.22kB done
1>#9 sha256:c607979be6d9b13f8a325f54f05f3c17245e4b72899e765c1c630ef432cfeb42 5.66kB / 5.66kB done
1>#9 CANCELED
1>ERROR: failed to solve: error from sender: context canceled
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: Docker command failed with exit code 1.
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: 2023/12/12 13:19:16 http2: server: error reading preface from client //./pipe/docker_engine: file has already been closed
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #0 building with "default" instance using docker driver
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #1 [internal] load .dockerignore
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #1 transferring context: 464B done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #1 DONE 0.0s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #2 [internal] load build definition from Dockerfile
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #2 transferring dockerfile: 1.15kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #2 DONE 0.0s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #3 [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #3 DONE 0.0s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #4 [internal] load metadata for mcr.microsoft.com/dotnet/sdk:8.0
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #4 DONE 0.6s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #5 [base 1/2] FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #5 DONE 0.0s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 [base 2/2] WORKDIR /app
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 CACHED
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 [final 1/2] WORKDIR /app
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 CACHED
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #8 [internal] load build context
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #8 transferring context: 203.60kB 0.0s done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #8 CANCELED
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #9 [build 1/7] FROM mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #9 resolve mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 0.0s done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #9 sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 1.08kB / 1.08kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #9 sha256:b1192f7b91d2cc1d81d865ff7b0f47b34ed1ca06fbac655d85f59761a5074e40 2.22kB / 2.22kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #9 sha256:c607979be6d9b13f8a325f54f05f3c17245e4b72899e765c1c630ef432cfeb42 5.66kB / 5.66kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #9 CANCELED
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: ERROR: failed to solve: error from sender: context canceled
1>Done building project "MyApp3.Api.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 1:19 PM and took 02.466 seconds ==========
What I find strange is that in Release mode it fails to run in Docker even if I am using the mcr.microsoft.com/dotnet/aspnet:8.0
base image. Basically it fails with the Dockerfile produced by VS with a new app. No changes done.
Build started at 1:21 PM...
1>------ Build started: Project: MyApp3.Api, Configuration: Release Any CPU ------
1>C:\Development\MyApp3\MyApp3.Api\MyApp3.Api.csproj : warning NU1803: You are running the 'restore' operation with an 'HTTP' source, 'http://my-private-artifactory/api/nuget/NuGet-virtual'. Non-HTTPS access will be removed in a future version. Consider migrating to an 'HTTPS' source.
1>Skipping analyzers to speed up the build. You can execute 'Build' or 'Rebuild' command to run analyzers.
1>MyApp3.Api -> C:\Development\MyApp3\MyApp3.Api\bin\Release\net8.0\MyApp3.Api.dll
1>docker build -f "C:\Development\MyApp3\MyApp3.Api\Dockerfile" --force-rm -t myapp3api --build-arg "BUILD_CONFIGURATION=Release" --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=MyApp3.Api" "C:\Development\MyApp3"
1>#0 building with "default" instance using docker driver
1>
1>#1 [internal] load .dockerignore
1>#1 transferring context: 464B done
1>#1 DONE 0.0s
1>
1>#2 [internal] load build definition from Dockerfile
1>#2 transferring dockerfile: 1.13kB done
1>#2 DONE 0.0s
1>
1>#3 [internal] load metadata for mcr.microsoft.com/dotnet/sdk:8.0
1>#3 ...
1>
1>#4 [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:8.0
1>#4 DONE 0.3s
1>
1>#3 [internal] load metadata for mcr.microsoft.com/dotnet/sdk:8.0
1>#3 DONE 0.6s
1>
1>#5 [internal] load build context
1>#5 transferring context: 236.58kB 0.0s done
1>#5 CANCELED
1>
1>#6 [build 1/7] FROM mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b
1>#6 resolve mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 0.0s done
1>#6 sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 1.08kB / 1.08kB done
1>#6 sha256:c607979be6d9b13f8a325f54f05f3c17245e4b72899e765c1c630ef432cfeb42 5.66kB / 5.66kB done
1>#6 sha256:b1192f7b91d2cc1d81d865ff7b0f47b34ed1ca06fbac655d85f59761a5074e40 2.22kB / 2.22kB done
1>#6 CANCELED
1>
1>#7 [base 1/2] FROM mcr.microsoft.com/dotnet/aspnet:8.0@sha256:f4cb736b1220b1013e7a0f77e49487c5cc1fe643bf41a750306c4a1caa7faa97
1>#7 resolve mcr.microsoft.com/dotnet/aspnet:8.0@sha256:f4cb736b1220b1013e7a0f77e49487c5cc1fe643bf41a750306c4a1caa7faa97 0.0s done
1>#7 sha256:f4cb736b1220b1013e7a0f77e49487c5cc1fe643bf41a750306c4a1caa7faa97 1.08kB / 1.08kB done
1>#7 sha256:c169967a40741870f5ca321d11d77f8850e04c53895461620c1dffd97567ccf3 2.72kB / 2.72kB done
1>#7 sha256:2b84def63597bc43496638f55c82c5da352dc0bdf2ea0375f23f414a2d90a6d4 1.58kB / 1.58kB done
1>#7 CANCELED
1>ERROR: failed to solve: error from sender: context canceled
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: Docker command failed with exit code 1.
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #0 building with "default" instance using docker driver
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #1 [internal] load .dockerignore
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #1 transferring context: 464B done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #1 DONE 0.0s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #2 [internal] load build definition from Dockerfile
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #2 transferring dockerfile: 1.13kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #2 DONE 0.0s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #3 [internal] load metadata for mcr.microsoft.com/dotnet/sdk:8.0
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #3 ...
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #4 [internal] load metadata for mcr.microsoft.com/dotnet/aspnet:8.0
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #4 DONE 0.3s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #3 [internal] load metadata for mcr.microsoft.com/dotnet/sdk:8.0
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #3 DONE 0.6s
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #5 [internal] load build context
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #5 transferring context: 236.58kB 0.0s done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #5 CANCELED
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 [build 1/7] FROM mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 resolve mcr.microsoft.com/dotnet/sdk:8.0@sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 0.0s done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 sha256:bb65e39b662be0265f780afae9cdbfcaa315ef63edb245ad9fb2aa1aabca0b6b 1.08kB / 1.08kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 sha256:c607979be6d9b13f8a325f54f05f3c17245e4b72899e765c1c630ef432cfeb42 5.66kB / 5.66kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 sha256:b1192f7b91d2cc1d81d865ff7b0f47b34ed1ca06fbac655d85f59761a5074e40 2.22kB / 2.22kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #6 CANCELED
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014:
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 [base 1/2] FROM mcr.microsoft.com/dotnet/aspnet:8.0@sha256:f4cb736b1220b1013e7a0f77e49487c5cc1fe643bf41a750306c4a1caa7faa97
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 resolve mcr.microsoft.com/dotnet/aspnet:8.0@sha256:f4cb736b1220b1013e7a0f77e49487c5cc1fe643bf41a750306c4a1caa7faa97 0.0s done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 sha256:f4cb736b1220b1013e7a0f77e49487c5cc1fe643bf41a750306c4a1caa7faa97 1.08kB / 1.08kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 sha256:c169967a40741870f5ca321d11d77f8850e04c53895461620c1dffd97567ccf3 2.72kB / 2.72kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 sha256:2b84def63597bc43496638f55c82c5da352dc0bdf2ea0375f23f414a2d90a6d4 1.58kB / 1.58kB done
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: #7 CANCELED
1>C:\Development\MyApp3\MyApp3.Api\Dockerfile : error CTC1014: ERROR: failed to solve: error from sender: context canceled
1>Done building project "MyApp3.Api.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 1:21 PM and took 02.131 seconds ==========
I want to propose and try a different approach (in parallel): Could you please provide a working Asp.Net Web Api (7 or 8) sample that uses jammy-chiseled base image?
Having something that works on your local environment it would help me:
@danegsta I am getting the same error trying to use the chiseled images (using the Dockerfile) with VS2022 Preview 17.9.0 2.1
Update: After some further testing, it seems like Visual Studio tries to run the debugger even in the Release configuration that is started with Ctrl + F5 (wihout debugging). So it still uses "tail -f" as the entrypoint (which the chiseled images do not support). Is this a bug? I thought the tailf -f command was only supposed to run in debug mode with fastmode enabled.
The whole approach of using "tail -f" seems to conflict with the chiseled images. In Rider, I can run with or without Docker fast mode, and it works with chiseled images for both debugging and no debugging.
Hi. Any updates? :)
In my case, to make it work, I had to launch the compose up from Visual Studio Code. It doesn't work from Visual Studio 2022.
@blinchi Can you please share your Dockerfile? And maybe a sample project that works? I didnt manage so far to run even the VS template using chiseled base image :( I would like to continue from something that works..
It easily works in JetBrains Rider, since they don't use the tail command and they also have the "fast mode". It's not a free IDE though.
@Arclight3 / @HummingMind , we have a workitem on our internal backlog to investigate VS tooling support for the chiseled / distroless images. We plan to start that investigation soon. For now, one workaround is to use our default scaffolded image for local debugging and chiseled for prod. Correct that currently we do require tail for F5 / Ctrl - F5.
Hello @Arclight3 , I can share the Dockerfile, but as @HummingMind said, it only works in Visual Studio Code or JetBrains Rider. Therefore, for now, you will not be able to use it to run from Visual Studio 2022. I want to thank @HummingMind for helping me with the problem, when he said it worked for him in Rider, I tried it in VS Code and it worked.
`FROM mcr.microsoft.com/dotnet/aspnet:8.0-jammy-chiseled as base WORKDIR /app EXPOSE 8080
FROM mcr.microsoft.com/dotnet/sdk:8.0-jammy AS build
WORKDIR /src
COPY ["blinchi.Api/blinchi.Api.csproj", "blinchi.Api/"] COPY ["blinchi.App.Abstractions/blinchi.App.Abstractions.csproj", "blinchi.App.Abstractions/"] COPY ["blinchi.Data/blinchi.Data.csproj", "blinchi.Data/"]
RUN dotnet restore "blinchi.Api/blinchi.Api.csproj" --runtime linux-x64 COPY . . WORKDIR "/src/blinchi.Api" RUN dotnet publish "blinchi.Api.csproj" -c Release -o /app/publish /p:UseAppHost=true --no-restore --runtime linux-x64 --self-contained true /p:PublishTrimmed=true /p:PublishSingleFile=true
FROM mcr.microsoft.com/dotnet/runtime:8.0-jammy-chiseled AS final WORKDIR /app EXPOSE 8080 COPY --from=build /app/publish . ENTRYPOINT ["./blinchi.Api"]`
Thanks @blinchi.
As a work-around you can take advantage of multi-stage build to Debug against the full Ubuntu image but publish against the chiseled image. Here is a commit where I took a dockized console app and updated it to publish using the chiseled image w/o breaking local debugging: https://github.com/NCarlsonMSFT/ChiseledExample/commit/5fe5668a58b2491277df53f40f3dc341a18ea443
Any updates?
This is something we are currently working on but it is too early to give any ETA of when we have something. Will keep this updated when we know more. For now I would suggest looking at @NCarlsonMSFT workaround.
@Arclight3. @topfunet : This is now supported in 17.10 Preview 2
Great news! Thank you @NCarlsonMSFT!
With 17.10 release, found this has been fixed, now aspnet:8.0-jammy-chiseled image CAN use for debugging in VS2022. Thank you @NCarlsonMSFT !
Really? I updated to 17.10, but still get the same error when debugging. Anything else that needs to be done, except updating VS, to get it working?
yes, i just tried, it's working. Maybe try updating Docker?
Yes. Got it working. Though I'm running Rancher (dockerd). But after deleting all images (aspnet etc.) it worked as a charm.
Thanksf or confirmation. Closing this since now working 17.10
Describe the Bug
I have a .net 7 Web API with this config:
I am using the latest version of Visual Studio (17.8.1) and Docker (4.25.2). I have the .net 7 (7.0.311) and .net 8 (8.0.100) SDKs installed (latest patches).
I have this Dockerfile:
My launchSettings.json is:
Initially I was using the
mcr.microsoft.com/dotnet/aspnet:7.0
base image and everything worked fine. After I update the Dockerfile to use themcr.microsoft.com/dotnet/aspnet:7.0-jammy-chiseled
image (or the 8.0-jammy-chiseled), I get this error in Visual Studio when I run the application in Docker:I have read and followed the instructions from this page: https://github.com/dotnet/dotnet-docker/blob/main/documentation/ubuntu-chiseled.md and I think my Dockerfile looks ok. I think it's a support problem with Visual Studio or the
Microsoft.VisualStudio.Azure.Containers.Tools.Targets
NuGet package regarding the newjammy-chiseled
Docker images.Please let me know if I can provide more information.
Steps to Reproduce
Other Information
Output of
docker version
Client: Cloud integration: v1.0.35+desktop.5 Version: 24.0.6 API version: 1.43 Go version: go1.20.7 Git commit: ed223bc Built: Mon Sep 4 12:32:48 2023 OS/Arch: windows/amd64 Context: default
Server: Docker Desktop 4.25.2 (129061) Engine: Version: 24.0.6 API version: 1.43 (minimum version 1.12) Go version: go1.20.7 Git commit: 1a79695 Built: Mon Sep 4 12:32:16 2023 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.6.22 GitCommit: 8165feabfdfe38c65b599c4993d227328c231fca runc: Version: 1.1.8 GitCommit: v1.1.8-0-g82f18fe docker-init: Version: 0.19.0 GitCommit: de40ad0
Output of
docker info
Client: Version: 24.0.6 Context: default Debug Mode: false Plugins: buildx: Docker Buildx (Docker Inc.) Version: v0.11.2-desktop.5 Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe compose: Docker Compose (Docker Inc.) Version: v2.23.0-desktop.1 Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe dev: Docker Dev Environments (Docker Inc.) Version: v0.1.0 Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe extension: Manages Docker extensions (Docker Inc.) Version: v0.2.20 Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe init: Creates Docker-related starter files for your project (Docker Inc.) Version: v0.1.0-beta.9 Path: C:\Program Files\Docker\cli-plugins\docker-init.exe sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.) Version: 0.6.0 Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe scan: Docker Scan (Docker Inc.) Version: v0.26.0 Path: C:\Program Files\Docker\cli-plugins\docker-scan.exe scout: Docker Scout (Docker Inc.) Version: v1.0.9 Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe
Server: Containers: 34 Running: 0 Paused: 0 Stopped: 34 Images: 51 Server Version: 24.0.6 Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Using metacopy: false Native Overlay Diff: true userxattr: false Logging Driver: json-file Cgroup Driver: cgroupfs Cgroup Version: 2 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: io.containerd.runc.v2 runc Default Runtime: runc Init Binary: docker-init containerd version: 8165feabfdfe38c65b599c4993d227328c231fca runc version: v1.1.8-0-g82f18fe init version: de40ad0 Security Options: seccomp Profile: unconfined cgroupns Kernel Version: 6.4.16-linuxkit Operating System: Docker Desktop OSType: linux Architecture: x86_64 CPUs: 16 Total Memory: 11.68GiB Name: (none) ID: df2cdba8-b0cb-46d8-b811-71928a942c2c Docker Root Dir: /var/lib/docker Debug Mode: false HTTP Proxy: http.docker.internal:3128 HTTPS Proxy: http.docker.internal:3128 No Proxy: hubproxy.docker.internal Experimental: false Insecure Registries: hubproxy.docker.internal:5555 127.0.0.0/8 Live Restore Enabled: false
WARNING: daemon is not using the default seccomp profile
Just to track things, originally I reported this issue here: https://github.com/dotnet/dotnet-docker/issues/5025.