Comments (20)
@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.
from dockertools.
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:
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?
from dockertools.
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.
from dockertools.
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"]`
from dockertools.
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: NCarlsonMSFT/ChiseledExample@5fe5668
from dockertools.
@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?
from dockertools.
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.
- Building the docker layers in this order (build -> final) fails all the time, no matter what image I am using for the sdk or the runtime. The commented FROM statements shows what other combinations I tried (6 total):
# 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
# Final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:7.0 as final
#FROM mcr.microsoft.com/dotnet/aspnet:7.0-jammy as final
#FROM mcr.microsoft.com/dotnet/aspnet:7.0-jammy-chiseled 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
cli_log_1.txt
- 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):
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"]
- Building the docker layers in this order (base -> build -> final) with the following images fail from both VS and CLI. The commented FROM statements shows what other combinations I tried (2 total):
FROM mcr.microsoft.com/dotnet/aspnet:7.0-jammy-chiseled 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"]
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
from dockertools.
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
from dockertools.
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 yourdotnet publish
command, but I don't see in your .csproj aDockerfileBuildArguments
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 yourdotnet 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 followingCOPY
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.
from dockertools.
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 ==========
from dockertools.
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:
- Understand if my local environment has problems
- Compare with the VS template or my custom app and see what am I missing
from dockertools.
@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.
from dockertools.
Hi. Any updates? :)
from dockertools.
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.
from dockertools.
@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..
from dockertools.
Thanks @blinchi.
from dockertools.
Any updates?
from dockertools.
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.
from dockertools.
Related Issues (20)
- Problem with API developed in Visual Studio 2022 Net Core 6 with Docker compatibility: Works in Debug but fails in Release HOT 2
- Multiple unlisted versions available on nuget.org HOT 7
- Docker Compose project doest not support secrets in `docker-compose.yml` HOT 3
- Visual Studio 2022 and Docker project debugging issues HOT 6
- Un-escaped JSON in `AzureServiceAuth\tokenprovider.json` HOT 3
- User secrets not available for isolated function app HOT 3
- Write access to /home required for functions tooling to create /home/.azurefunctions folder HOT 5
- ENC1002 Cannot apply changes. Unexpected error: 'An item with the same key has already been added. Key: 420' HOT 8
- Not found application or .NET SDKs issue when running docker-compose HOT 1
- Windows container .NET 8 RC: MSB3052: The parameter to the compiler is invalid, '/define:$BUILD_CONFIGURATION' HOT 1
- VisualStudioCredential is supported in .NET Framework container? HOT 1
- Problem Installing Docker HOT 1
- Program does not contain a static 'Main' method suitable for an entry point docker HOT 1
- Allow Running Docker Compose inside of WSL2 with VS2022 HOT 1
- The "Configuration" parameter is not supported by the "WaitForWarmupCompletion" task HOT 4
- Relative paths in generated dockerfile appear to be incorrect HOT 4
- Check whether the file has been patched update HOT 5
- DockerfileRunArguments not used when debugging HOT 8
- Unable to push an image to a repository with multiple image tags HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dockertools.