Use Visual Studio debugger with ASP.NET Core web app running in Kubernetes?

Question

Our team wants to be able to run the Visual Studio debugger against deployed instances of our ASP.NET application to our internal Kubernetes cluster. I need to figure out how to finish the puzzle but I'm not very familiar with Visual Studio 2019.

• The Docker image is compiled with the official .NET Core images and has /vsdbg populated with the latest version (which does not support --attach).
• Visual Studio works with my Docker Desktop.
• Kubectl is correctly configured. I can use either the kubernetes cluster included with Docker Desktop or our internal kubernetes cluster for testing.
• Azure is currently not an option. I understand from the documentation that this is what Microsoft prefers me to do.

How should I configure Visual Studio to be able to do this?

Answer 1

Ok. Let’s get it started. First of all make sure that you have published your app in Debug mode! I prefer to use a new Docker feature multi-stage build for building my images so I would write something like this in the end of a build stage in Dockerfile:

RUN dotnet publish -c Debug -o ./results

To push images to Minikube I do use the local container registry as described here. But you can do it as you usually do. When you have your container up and running we can start hacking to it. I will use Powershell for that purpose but the same can be easily rewritten in any other terminal language. You can follow tutorial step by step and execute commands in your terminal one by one checking var’s values with echo command when necessary. In your *.yml file you should have a selector described something like this:

selector:
  matchLabels:
    app: mywebapp

Grab it and use to define a $Selector var in your Powershell terminal:

$Selector = 'app=mywebapp'

You need to find a pod where your containerized application is running by its selector:

$pod = kubectl get pods --selector=$Selector -o jsonpath='{.items[0].metadata.name}';

Assuming that you have only one container on the pod now you can execute commands on that container. By default container does not have vsdbg installed so go ahead and install it:

kubectl exec $pod -i -- apt-get update;
kubectl exec $pod -i -- apt-get install -y unzip;
kubectl exec $pod -i -- curl -sSL https://aka.ms/getvsdbgsh -o '/root/getvsdbg.sh';
kubectl exec $pod -i -- bash /root/getvsdbg.sh -v latest -l /vsdbg;

Next, you need to find PID of your app inside of the container:

$prid = kubectl exec $pod -i -- pidof -s dotnet;

Normally it is equal to 1 but it is better to make fewer assumptions. That’s it. Now you can start a debugger:

kubectl exec $pod -i -- /vsdbg/vsdbg --interpreter=mi --attach $prid;

Don’t forget to execute the following commands before you close the window otherwise your app will stuck forever:

-target-detach
-gdb-exit

Let’s put everything together, create a reusable script and save it somewhere near to the roots since you can use it with all your ASP.NET Core projects:

param(
    # the selector from your yml file
    #  selector:
    #    matchLabels:
    #      app: myweb
    # -Selector app=myweb
    [Parameter(Mandatory=$true)][string]$Selector
)

Write-Host '1. searching pod by selector:' $Selector '...';
$pod = kubectl get pods --selector=$Selector -o jsonpath='{.items[0].metadata.name}';

Write-Host '2. installing updates ...';
kubectl exec $pod -i -- apt-get update;

Write-Host '3. installing unzip ...';
kubectl exec $pod -i -- apt-get install -y --no-install-recommends unzip;

Write-Host '4. downloading getvsdbgsh ...';
kubectl exec $pod -i -- curl -sSL https://aka.ms/getvsdbgsh -o '/root/getvsdbg.sh';

Write-Host '5. installing vsdbg ...';
kubectl exec $pod -i -- bash /root/getvsdbg.sh -v latest -l /vsdbg;

$cmd = 'dotnet';
Write-Host '6. seaching for' $cmd 'process PID in pod:' $pod '...';
$prid = kubectl exec $pod -i -- pidof -s $cmd;

Write-Host '7. attaching debugger to process with PID:' $pid 'in pod:' $pod '...';
kubectl exec $pod -i -- /vsdbg/vsdbg --interpreter=mi --attach $prid;

Now you can execute this script like this when the terminal is running from the script folder:

powershell -ExecutionPolicy Bypass -File kubedbg.ps1 -Selector app=mywebapp

But aren’t we supposed to be debugging from Visual Studio? Yes! Let’s go further and launch our terminal process from Visual Studio MIEngine. Open your project in Visual Studio. Add new XML file with the following content and name it kubedbg.xml:

<PipeLaunchOptions xmlns="http://schemas.microsoft.com/vstudio/MDDDebuggerOptions/2014"
    PipePath="powershell" TargetArchitecture="x64" MIMode="clrdbg"
    PipeArguments="
      -ExecutionPolicy Bypass
      -File C:\kube\kubedbg.ps1
      -Selector app=mywebapp">
  <LaunchCompleteCommand>None</LaunchCompleteCommand>
</PipeLaunchOptions>

In -File parameter you need to specify absolute path to the script file we created before. Then press Ctrl+Alt+A to open Command Window and run the following command: Debug.MIDebugLaunch /Executable:dotnet /OptionsFile:absolute_path_to_kubedbg_xml This command will start the debugging process inside Visual Studio with all standard benefits you would expect. But don’t stop debugging any other way than by pressing Detach All from Debug menu! Although this command is not very convenient to write all the time. Luckily in Visual Studio, you can specify aliases for commands with parameters. Eventually, you would need a new kubedbg.xml file for each project. With this in mind go ahead and create your first alias by typing the following command in Command Window:

alias kubedbg.mywebapp Debug.MIDebugLaunch /Executable:dotnet 
/OptionsFile:absolute_path_to_kubedbg.xml

After that, you can start debugging just by executing kubedbg.mywebapp in Command Window. Even better you can run the same command from the Find toolbar Combobox but with prefix: >kubedbg.mywebapp. That’s not difficult since there is a text completion too. You can read more about command aliases here. Happy debugging! PS: As a bonus absolutely the same way you can debug your app even when running inside a public cloud. When kubectl is assigned to a cluster in the public cloud it just works with the same script and making fewer assumptions paid back since inside real cluster process ID is not equal to 1

Original author: https://medium.com/@pavel.agarkov/debugging-asp-net-core-app-running-in-kubernetes-minikube-from-visual-studio-2017-on-windows-6671ddc23d93

Answer 2

Since my original article mentioned in the accepted answer got outdated I wrote a new one for Visual Studio 2019: https://link.medium.com/rGycPY6NGdb

PS: To keep it DRY and easy to update I won't copy & paste it here ;)