DEV Community

Cover image for The problem of debugging a Docker project in Visual Studio
Davidson Sousa
Davidson Sousa

Posted on • Originally published at davidsonsousa.net on

The problem of debugging a Docker project in Visual Studio

I’ve been reading about Docker for a couple of weeks already and, few days ago, I decided to create a small proof of concept. You know, just to make sure that I understood everything well. But I ended up running into problems which resulted in a small thread on Twitter that I am expanding here.

Everything started when I decided to use Visual Studio 2019 to take care of Docker for me. In case you don’t know, you can “dockerize” existing projects…

add-docker-support.png

…or create a “dockerized” project from scratch.

enable-docker-support.png

I decided to do both since I was just playing around. The result was a couple of duplicated files that I ended up deleting later. Perhaps the best option is to “dockerize” a project after it’s been created. Anyway, here is the result so far:

solution-explorer.png

From that point I just wanted to see if what would happen when I run the project. So, I did my usual: Start the project without debugging (Ctrl+F5). I prefer to do that because it gives me the feeling that I am running closer to a real application. Not to mention that I would not hit random breakpoints I’ve added and forgot to disable.

debug-menu.png

Whenever I want to debug, I simply attach the Visual Studio to the process of the project (Ctrl+Alt+P).

debug-menu-attach.png

That opens a dialog where I can select the process. But since I am using Docker, I must select the connection target, which is the name of the container, and the process, which is “dotnet”.

connection-target.png

There is one extra step here which is the type of the code. Since I am using Linux Containers* , I will choose the only option available.

code-type.png

That should be it. The code would be attached, and I would be able to debug. Unfortunately, I got an exception after a couple of seconds saying that the launch debug adapter failed to launch.

exception.png

Since the exception was also pointing to the Output Window, it was a good idea to check there too. And that was the moment I regret that I don’t really know Linux:

output-window.png

The most important part of the whole text from the Output Window is written in red, at the bottom:

ERROR: Command 'unzip' not found. Install 'unzip' for this script to work.

It turns out that I didn’t have that “unzip” installed in my container. How to install? No idea. But after some investigation I found a dockerfile that could help me as it seemed to match mine. Or at least had the same principle. The most important thing for me in that file was what seemed to install “curl”. So, I copied that part and pasted into my own dockerfile, just being careful to replace unzip with curl.

dockerfile.png

Once I’ve done that, I repeated my debugging steps: run without debug and attach. At this time it works without any problem. For someone who isn’t used to work with Docker I noticed that it takes a couple of seconds to attach when compared with a normal run. But when I detach and reattach it goes as fast as I am used to. And all breakpoints were hit.

Maybe this is a small bug in the dockerfile generated by Visual Studio, which means I should learn how to create my own dockerfile manually until it’s fixed. Or maybe I am missing something. Another thing I noticed: The attach doesn’t work with Windows Containers and I would have to use F5 to debug it.

I am still learning and there is a lot to understand there.

*Note: I am using Linux Containers because Windows Containers didn't even allow me to debug properly. My best guess is that VS and Docker still need to work on their relationship.

Discussion (0)