DockerfileRunArguments not used when debugging

[groogiam]

It appears that the DockerfileRunArguments passed by the launch settings are only honored during container warmup. They are not passed when docker run is called when debugging. I have a console app that needs to connect to an existing network which is created by another compose project but can't because that project is started after the warmup period. This makes it impossible to get the console app container on the same network to enable debugging.

[NCarlsonMSFT]

My guess is that you are using an out of date version of the NuGet. In my testing version 1.10.11+ honored DockerfileRunArguments from the launch profile.

[groogiam]

@NCarlsonMSFT I am using version 1.19.5 of the package which appears to be the latest. The functionality works fine if I set set the DockerfileRunArguments via an msbuild property but not from launch settings.

[NCarlsonMSFT]

@groogiam can you give more details on what you are seeing? I tested by setting an environment variable using the run arguments and it was available on each run. What are you not seeing in the subsequent runs?

[groogiam]

I am attempting to pass these arguments --network=another-compose-network -v /var/run/docker.sock:/var/run/docker.sock

The project that is not working works as an agent for a larger compose project. In product the main services would spin up this project in a container. In order to debug this agent process I first start visual studio and run the other compose project. Then I run this project in debug mode. Depending on what was selected as the Startup Project in Visual studio when I open it I get different behavior.

If the agent project is select the run arguments are executed. However, if I kill the container and rerun the project in visual studio the arguments are not added.

If the other compose project was the default startup project then that is warmed up and if I switch to the agent project the container is not warmed up. When I run / debug the container is run but the arguments are not present.

Again this behavior only seems to manifest when using launchSettings. Everything appears to work correctly with the msbuild properties added directly to the csproj.

[NCarlsonMSFT]

Sorry for the delay on responding, I was out with Flu. I tested again passing the --network in my single project to connect to a service in a running compose project and was able to do so even after rebuilding. My repro steps:

• Create a new API project
  • Add compose support
• Create a new project
  • Add just Container support (no compose)
  • Add DockerfileRunArguments with the value --network=another-compose-network -v /var/run/docker.sock:/var/run/docker.sock
  • Clean to remove all containers
  • Compose up on the compose project
  • F5 on the single project

My single container project was able to connect and looking at the build log I could see the docker run command included passing my DockerfileRunArguments. Can you check the output window's build pane and see what your docker run command looks like?

[groogiam]

I had checked the docker command prior to submitting the issue and it did not include the runfile arguments. I'll run through the entire procedure again hopefully tomorrow and send you the output.

In your procedure are you running the 'Compose Up' step manually via the command line or is Visual Studio doing that as part of the container warmup? In my testing Visual Studio takes care of this at start or by debugging / running the compose project. I am unable to remove the compose project via the docker gui while visual studio is running also. Not sure these are material but there does appear to be some small differences in procedure here.

Thanks for your help.

[groogiam]

@NCarlsonMSFT I went back and retested my workflow and things now appear to be working correctly. I'm not sure what I was doing differently when I reported this but I can no longer reproduce the behavior. Thanks again for taking the time to setup a repro and validate it is working correctly. Sorry for wasting your time trying to reproduce this.

[NCarlsonMSFT]

@groogiam NP, glad it's working for you now!