July 30th, 2020
Since update 16.5 of Visual Studio 2019, debugging processes inside of a Windows container is natively supported. More details in the release notes.
Previously, a common method of debugging inside the container was to mount the remote debugger folder found in the Visual Studio directory on the host as a docker volume and then run the remote debugger in the image entry point.
I found on my team that this could get problematic when team members were using different versions of Visual Studio. For example, the VS install for user running Visual Studio Enterprise, Professional and Community are all different. As is the paths for preview versions of VS.
None of this is required anymore. You can remove any volume mounts for the remote debugger from your
Instead, remote debugging happens natively in Visual Studio 2019 16.5+ and all you need to do is follow these simple steps to start debugging your containerized sites:
Debug > Attach to processor hit Ctrl+Alt+P.
Next to the
Attach To field, select the
Debug these code types:radio and then check the
Managed (v4.6, v4.5, v4.0)checkbox.
Select "w3p.exe" to being debugging.
Alternatively, if you have the VS Container Tools Extension installed, you can also attach your debugger using that.
If the "Containers" window is not open, you can go to
View > Other Windows and select "Containers" to open it.
From within the "Containers" window, find your container you want to attach to (i.e. "mysitecm1"), right-click and then select
Attach to process. In the dialog box that opens, select "w3p.exe". If you don't see it, make sure "Show processes from all users" is checked. Then hit
My team ran across some DNS issues inside the containers.
For some reason, they were unable to resolve Microsoft's domain when downloading the VS remote debugger.
We resolved this by adding the following DNS configuration to our
cm: # ... dns: - 126.96.36.199 - 188.8.131.52
This tells the CM service to use Cloudflare's DNS server -- with Google's as a backup -- for DNS resolution. This step may not be necessary for you. By default, the container should try to use whatever DNS settings the host machine has set.
That's it. You can debug like you would with a typical, non-containerized local site.
Happy bug hunting!