Visual Studio 2017 Docker - change the target for multi stage builds

Question

If I have a docker file that has multiple stages (such as base and build), is there a way to change the docker command that visual studio uses when debugging the container - it seems to use the first build in the docker file, without invoking the subsequent stages.

Here is my docker file:

FROM microsoft/aspnetcore:2.0.3 AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/aspnetcore-build:2.0.3 AS build
WORKDIR /src
COPY *.sln ./
COPY Web/Web.csproj Web/
RUN dotnet restore
COPY . .
WORKDIR /src/Web
RUN dotnet build -c Release -o /app

FROM build AS publish
#RUN npm install
RUN dotnet publish -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
# Set the entry point of the application.
ENTRYPOINT ["dotnet", "Web.dll"]

When I hit f5, it will create the container with the base image, and subsequently result in error because the project needs the node install of the aspnetcore-build image; I can resolve this by changing the base image to be the aspnetcore-build.

However, is there a way to tell the project in visual studio that it is a multi-stage build and needs to use build?

I am very new to docker so perhaps I am missing something obvious.

Answer 1

To use build target configuration from docker file, you need to add a docker-compose.vs.debug.yml file. In that file, just specify build target for the service and that's it.

Example:

version: '3.4'

services:
  my.api:
    build:
      target: build

Answer 2

According to this blog post, Visual Studio builds only the first image when you hit F5. However, I observed that this happens when using the Debug configuration only (as correctly stated by Matheus' Answer).

I changed all solution configurations to use the Release configuration for the docker project (.dcproj) only. This will build all images and correctly executes the multi-stage build without setting --target to whatever.

EDIT

However, this configuration cannot be debugged from within Visual Studio. To allow for local debugging inside containers, you should have a separate Dockerfile that does not use a multistage build.