VSCode

Articles

• Debug containerized apps ⭐
• Debugging in VSCode ⭐
• Integrate with External Tools via Tasks ⭐
• Schema for tasks.json
• Task Provider
• Configuring launch.json for C# debugging
• Customize the Docker extension ⭐
• How to Debug Dockerized .NET Core Apps in VS Code ⭐
• Showing errors in docker file in docker-run ⭐
• DEBUGGING YOUR .NET CORE IN DOCKER APPLICATIONS WITH VS CODE ⭐
• Remote debug your ASP.NET Core container on OpenShift with Visual Studio Code
• Debugging Windows Subsystem for Linux ⭐
• Attaching to remote processes ⭐
• Remote Debugging On Linux Arm ⭐
• How to debug a .NET Core app in Docker with VSCode
• How to properly override the ENTRYPOINT using docker run ⭐
• ENTRYPOINT (default command to execute at runtime) ⭐
• Showing errors in docker file in docker-run #3831
• Debugging into .NET container fails when OutputPath is set to absolute path #3597

Videos

• Debugging .NET Core in Docker with VSCode ⭐
• Debug docker container | live debug docker image using VsCode

Samples

• microsoft/vscode-extension-samples - Sample code illustrating the VS Code extension API.
• thehaseebahmed/vscode-dotnet-docker-debug
• the-nerbs/docker-debug-repro

Notes

• docker exec -it docker-remote-debugging bash for interact with container
• install debugger on wsl, with running wsl withRunAsAminstrator and curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v vs2019 -l ~/vsdbg in ubuntu home path ${HOME}/vsdbg or in git bash in windows %userprofile%\vsdbg path
• connecting vsdbg debugger to docker container with using vsdbg inner container and ssh to our local source code
• pipeTransport will run exec -i <container name> /vsdbg/vsdbg inner container
• dockerRun.volumesAdds the following volumes as required: the local application folder, the source folder, the debugger folder, the NuGet package folder, and NuGet fallback folder.
• docker-build task only builds target stage here base stage without any entrypoint for running container and other stages will skip and after running container in the launch settings, debugger will run inner container with docker exec -i catalogs-dev /remote_debugger/vsdbg and vsdbg command. Our container app/ working directory mapped to local ECommerce.Services.Catalogs.Api folder and will launch project with appProject attribute configuration on our launch settings setting (see extension code)
• when we run app dll, inner api project working directory (will resolve to current working directory for app) that contains appsetings.json files or inner bin directory because when run app dll in this directory app working directory and current working directory will be set bin directory and because appsettings.json are there, so app can find this appsettings.json files in current working directory but if we run app dll outside this directories app current working directory will be changed, and it can't find appsettings.json files in current working directory, so we should explicitly specify working dir in cwd, this problem doesn't exist for .csproj files and their working dir always resolve correctly based on api project
• To debug programs built on computers other than the Visual Studio Code computer (the dll and its pdbs are on the container), Visual Studio Code needs to be hold how to map file paths (SourceMap attribute), actually it maps path inner container pdbs to local path. This rule tells the debugger to change any file paths in container pdbs from source in SourceMap (container pdb path) to target in SourceMap (our local code) and replace it with the local code path. Paths in the containers pdbs, built and get from path during dotnet build in the dockerfile.
• In debug docker run we use full build image for debugging, but we change dcokerfile entrypoint during docker run for preventing launch app in docker container but with using new entrypoint our stage will run on app working directory and then in our launch.json we launch our app inner container with connecting to catalogs-debug container with pipeTransport and vsdbg (internally use dcoker exec and run vsdb on container) and then with using coreclr type and program to run, it will run this program with dotnet run by coreclr and passed args
• In docker run base with using base image, we use base image directly for running app, and we don't have any source code and nuggets and entrypoint (so our container not be launch) in base layer we should map source code and vsdbg as a volume or using in launch time in launch.json on base layer. In launch.json app will run with pipeTransport and type coreclr and after connecting to base layer container with running vsdb on the container and then coreclr will launch specified program with dotnet run on the container and pass args to dotnet run as launch program (nugget path, ... as --additionalProbingPath because our dll is in debug build and need to resolve all nugget dependecies that doesn't exist in this build).