Debugging through docker-compose stopped working

Question

Created a small .Net 5.0 application in Visual Studio 2019 and added docker-compose container orchestration support to it using linux containers. I set the docker-compose project as the default startup application in Visual Studio, and everything was going great for two days until I decided to alter my configuration so my container would have a stable port number instead of it randomly changing.

I'm not sure what I did but but Visual Studio doesn't attach to the container anymore, and the browser window that normally opens when the container starts no longer does. The container is running but the app doesn't respond to the new port number I'm trying or the older port number either.

The code builds fine in VS, the Dockerfile builds successfully, and the docker-compose up command runs in Visual Studio just fine.

I have portainer running in my docker-compose file and I can see that the container is running but it is not producing any logs. I logged into to my running container using portainer and installed the procps package like so: apt-get update; apt-get -y install procps. When I run ps I see that my app is not actually running.

root@46c62bf07df3:/app# ps l
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0  2195     0  20   0   3868  3280 do_wai Ss   pts/2      0:00 bash
0     0  2216  2195  20   0   7556  1212 -      R+   pts/2      0:00 ps l

Answer 1

Update: This continued to happen ever time a cow farted so I had to keep plugging away at the problem. I finally found this report that says its a known internal issue when docker-compose v2 is enabled.

The fix is to disable V2 using docker-compose disable-v2. You can verify it's disabled with docker-compose --version. They claim a real fix is in the works mid Oct-2021 and will be release soon. Also they claim Visual Studio 2022 preview already has the fix in it.

https://developercommunity2.visualstudio.com/t/Debugging-docker-compose-VS-cant-attac/1551330?entry=problem&ref=native&refTime=1636020527854&refUserId=09da1758-2dd4-4352-bba5-ea1f5e163268

I also wound up writing this powershell script to clean out all the garbage VS was caching so nothing stuck around.

$ErrorActionPreference = 'Stop'

# delete various folders from the root folder
if ((Test-Path -Path .vs)) {
    Remove-Item .vs -recurse -force -Verbose
}
if ((Test-Path -Path obj)) {
    Remove-Item obj -recurse -Verbose
}
if ((Test-Path -Path bin)) {
    Remove-Item bin -recurse -Verbose
}

# delete various folders recursively
$currentfolder = Get-Location
Get-ChildItem -Path $currentfolder -Directory -Include bin, obj -Recurse | Remove-Item -Force -recurse -Verbose
Get-ChildItem -Path $currentfolder -File -Include docker-compose.dcproj.user -Recurse | Remove-Item -Force -recurse -Verbose
Get-ChildItem -Path $currentfolder -Directory -Recurse -Attributes H | Where-Object { $_.Name.Contains('.vs') } | Remove-Item -Force -recurse -Verbose

# delete all volumes except those with the keep label
#docker volume prune --filter "label!=keep" -f

---

Original answer

Figured out how to get it working again, but I still don't know why it happens and it appears to randomly fubar now and then.

I wound up creating another temp starter application and adding container orchestration to it so I could see if it would run and also compare the files with my real application. The new temp app indeed ran successfully in docker-compose so I started looking at differences in various files between the two apps. All of them were minor diffs, and even after I updated my real application to match the temporary app's files it still wouldn't run.

I noticed that in Visual Studio 2019 you can actually see details about your running docker containers, and also noticed that it was showing me both the temp app and my real app that I cared about. So I went through all the container details for both and narrowed in on a label called com.microsoft.visualstudio.debuggee.arguments that was clearly missing something in my real app's container.

The temp application had that label set to :

--additionalProbingPath /root/.nuget/packages "/app/bin/Debug/net5.0/Test.dll"

but my real app instead had this, which is missing the path to the assembly needed to start/debug my application.

--additionalProbingPath /root/.nuget/packages ""

Visual Studio creates a file obj\Docker\docker-compose.vs.debug.g.yml and passes it to docker-compose when you debug, and that label is missing the magic sauce to get my app up and running.

I don't know why Visual Studio is fubaring this file but it continues to randomly happen.

These are the steps that finally got it working.

1. Close all instances of Visual Studio
2. Manually delete the following folders

.vs
bin
obj

3. Manually delete all .user files in the project.
4. Open Docker Desktop and remove the docker-compose stack created by your project.
5. Remove the docker images for your project(s)
6. Load your project and try to run it again.

Visual Studio should regenerate the file mentioned above with the correct bits this time and should attach to the container.