Custom ENTRYPOINT ignored by VS2017 when using docker-compose

[oleksii-udovychenko]

Introduction

I've tried to launch supervisord in a container to run both webpack-dev-server and .NET Core Web App at the same time (for development purposes).

I've created the following Dockerfile:

FROM microsoft/aspnetcore:1.1

(... omitted for brevity ...)

ENTRYPOINT ["supervisord"]

and the following supervisord.conf file:

[supervisord]
nodaemon=true

(... omitted for brevity ...)

[program:frontend]
command=/bin/bash -c "cd wwwroot && npm start"

[program:backend]
command=/bin/bash -c "dotnet App.dll"

When I hit F5, I see that supervisor doesn't start, so frontend and backend apps shouldn't start. The weird thing is that my App.dll starts successfuly. When I started supervisor manually from the container itself, I noticed that backend (which is my App.dll) can't be started (because it is already running), but frontend works fine:

After few more tries I realized that VS2017 starts my app behind the scenes and ignores my ENTRYPOINT because docker-compose.vs.debug.yml overrides the ENTRYPOINT with the following command:

entrypoint: tail -f /dev/null

Changing entrypoint in docker-compose.vs.debug.yml doesn't help, it seems that tail -f /dev/null command is required.

Problem

The problem is that I can't find where and how my app starts. Also, it would be great to know a way to change default VS2017 behavior, so I can stop VS2017 from launching my app and launch supervisord instead.

Maybe I am missing something?

I was able to isolate and reproduce this issue(?).

Steps to reproduce

1. Create a new solution using standard "Console App (.NET Core)" template
2. Right-click on a new console app and select "Add => Docker Support"
3. Open Dockerfile and change ENTRYPOINT to something that should cause an error.

FROM microsoft/dotnet:1.1-runtime
ARG source
WORKDIR /app
COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["DOESNOTEXIST"]

4. Hit F5

EXPECTED RESULT: Console app doesn't start.

ACTUAL RESULT:

[dazhao-msft]

The challenge is that we'd need to teach VS debugger to launch the app in the way defined above and then it'd need to figure out which processes to attach. This is something we don't support today.

[oleksii-udovychenko]

This is something we don't support today.

Will support this in future? I am working on a large enterprise project that consists of front-end (express + react) and back-end (asp.net webapi services + lots of cloud services). I am trying to migrate it to the docker containers on linux and it is imposible with the current state of tooling.

Are there any way to teach visual studio debugger attach window to connect to docker images and allow developers manually choose processes that they want to debug? As far as I see there is no way of doing this. I also tried to connect to docker containers using SSH but it didn't work for me (maybe I am missing something).

[pbering]

I have the same issue when I set the entrypoint in the compose file, it is always overridden by the entrypoint in docker-compose.vs.debug.g.yml. Is there a way to tell the tooling not to override this or some way defining which compose files that the tooling uses when building / starting? Right now I can't use the tooling since I need the ability to set the entrypoint during development.

[dweggemans]

Is there any workaround available? I have a case where I have to run some 3rd party software in the project container. I am able to download and install it in the docker file, but I am unable to run its services on container startup in any way. It just executes my project and ignores whatever I've configured as CMD or ENTRYPOINT.

[MikhailTymchukDX]

Same problem.
I have simple .NET Core console app which expects some args.
But this .yml files just overrides entrypoint and it seems specifying command does not work too (@dazhao-msft correct me if I wrong).

I found kind of workaround here: https://stackoverflow.com/a/40730210/644496
In short, we have to set environment variables in docker compose and read it at the start:

docker-compose.yml

version: '3'

services:
  app:
    environment:
      arg1: 'value1'
      arg2: 123

Program code:

class Program
{
    static void Main(string[] args)
    {
        var arg1 = Environment.GetEnvironmentVariables()["org"].ToString();
        var arg2 = Convert.ToInt32(Environment.GetEnvironmentVariables()["arg3"]);
    }
}}

[JoostvdB94]

@oleksii-udovychenko Did you find a working workaround?
I'm using a custom entrypoint.sh to do some adjustments in the hosts file of my docker container (at runtime), so i need this entrypoint too.

[oleksii-udovychenko]

@JoostvdB94 I don't use visual studio for building and running containerised projects. I just run them through docker-compose from the console and then attach debugger to one of the containers.

[brad-jones]

@oleksii-udovychenko do you have any pointers for attaching the debugger with Visual Studio? It's easy as with Visual Studio Code, eg:

"pipeTransport":
{
    "pipeProgram": "docker",
    "pipeCwd": "${workspaceRoot}",
    "pipeArgs": ["exec", "-i", "foo"],
    "debuggerPath": "/opt/vsdbg/vsdbg",
    "quoteArgs": false
}

Just trying to figure out how to do it with Visual Studio for my Windows buddies (I'm predominantly a Linux dev).

[dbreshears]

@brad-jones , you should be able to create a file named "docker-compose.vs.debug.yml and add this to the docker-compose project, overriding the entrypoint as necessary.. You can start by grabbing the \obj\Docker\docker-compose.vs.debug.g.yml and renaming it to remove the ".g" file. If this is found in the project we will pass along to docker-compose after the other arguments.

[labarilem]

@dbreshears , I have added a docker-compose.vs.debug.yml file in my docker-compose project:

<ItemGroup>
    <None Include="docker-compose.override.yml">
      <DependentUpon>docker-compose.yml</DependentUpon>
    </None>
    <None Include="docker-compose.vs.debug.yml">
      <DependentUpon>docker-compose.yml</DependentUpon>
    </None>
    <None Include="docker-compose.yml" />
    <None Include=".dockerignore" />
  </ItemGroup>

Its content is based on the \obj\Docker\docker-compose.vs.debug.g.yml file you mentioned. The only difference is the entrypoint property, which I have edited manually.

Still, the issue persists: when debugging with Docker, VS uses the \obj\Docker\docker-compose.vs.debug.g.yml file which is the same as before (i.e. does not take into account the entrypoint property that I manually edited).

Am I doing something wrong?

[dbreshears]

That certainly looks correct. Can you ensure your startup project is the docker-compose project. In 15.8 we added a single project docker experience, when I unloaded and reloaded docker-compose project when testing this just now, it gets reset to my WebApplication and therefore just does docker run in stead of compose. Also, are you on "Debug" solution config in VS when you F5? Can you share your build output. You should see something like this where the last "-f" argument to compose is docker-compose.vs.debug.yml

2>docker-compose -f "C:\Users\devinb\source\repos\WebApplication3\docker-compose.yml" -f "C:\Users\devinb\source\repos\WebApplication3\docker-compose.override.yml" -f "C:\Users\devinb\source\repos\WebApplication3\obj\Docker\docker-compose.vs.debug.g.yml" -f "C:\Users\devinb\source\repos\WebApplication3\docker-compose.vs.debug.yml" -p dockercompose14141838616008167745 --no-ansi config

[watsonsong]

I met the similar error, I use the visual studio docker tools, can add some argument to the ENTRYPOINT like this:
ENTRYPOINT ["dotnet", "MyApp.dll", "-e", "CONFIG_"]

But when I start to debug, the arguments I add is missing

[watsonsong]

So the entrypoint is replaced by the docker-compose.vs.debug.g.yml to tail -f /dev/null, it means when I launch by docker-compose in visual studio, it actually not run on docker at all?

[bwateratmsft]

@watsonsong When we launch the container in VS, we use that "tail -f /dev/null" command as a way to keep the container alive indefinitely. The app really is running in the container, but it is done via a "docker exec" call rather than the entrypoint. In the case of F5 (debug), we docker exec VSDBG and instruct it to run the app; in the case of Ctrl+F5 (launch w/o debug), we docker exec the app directly.

[watsonsong]

@bwateratmsft So is there a way I can modity the docker-compose.vs.debug.yml and edit the command line argument for my app?