Multiple Debug Configs with Multiple Build Tasks – VS Code

I’ve recently overcome one of my biggest bugbears with developing in VS Code. This may be something that was a massive oversight on my part, or it may be an extremely useful tip for my fellow developers.

The pain points arose if I had multiple .NET Core applications within the same git repository.

I would create my first application, write some code and then run the debugger to step through and test. In VS Code, this generates a small configuration file that contains a section that will look something like this.

{
    "name": ".NET Core Launch (web)",
    "type": "coreclr",
    "request": "launch",
    "preLaunchTask": "build",
    "program": "${workspaceFolder}/src/apps/JEasthamDev.MultipleDebugAPi/bin/Debug/netcoreapp3.1/JEasthamDev.MultipleDebugAPi.dll",
    "args": [],
    "cwd": "${workspaceFolder}/src/apps/JEasthamDev.MultipleDebugAPi",
    "stopAtEntry": false,
    "serverReadyAction": {
        "action": "openExternally",
        "pattern": "^\\s*Now listening on:\\s+(https?://\\S+)"
    },
    "env": {
        "ASPNETCORE_ENVIRONMENT": "Development"
    },
    "sourceFileMap": {
        "/Views": "${workspaceFolder}/Views"
    }
}

It’s that easy. I can now run my debugger and step through the code. Happy days.

But now I need to add a second application to the repo. Maybe I have a Web API for handling requests and a worker service that handles some arbritary background tasks.

I create the new project as normal and add a new debug config. All good up to now.

I make some changes to the code for the new application and then run the debugger. Interestingly, my first project is rebuilt before the debugger then attaches to my new project.

Less than ideal…

What’s going on?

For a long time, I just dealt with this. I would manually run dotnet build on my second project before launching the debugger and that was fine.

Frustrating when I forgot to re-build, but adequate.

Yesterday, I took a stand and decided to figure out what was happening.

Any folder structure that has been opened with VS Code, has a .vscode file created within the root folder you opened. Within, there are normally two files. Launch.json and tasks.json.

Launch.json

Launch.json contains the debug configuration we have already seen towards the start of the article. There should now be two JSON objects in here, with a slightly different program and cwd properties.

The incredibly important part of this file is the pre-launch task. You’ll notice, the pre-launch task is the same for both debug configuration.

Now where have we just seen something relating to tasks.

Tasks.json

Oh, that’s right. There is a file called tasks.json. On further inspection, this file is pretty standard. There will be a section for build, publish and watch. Three of the key commands used in the .NET Core CLI.

Looking at the build task (the one which both debug configs are using) you should quite quickly see there is a path to a specific .csproj file. Normally, this will be the first project you debugged.

Initially, I tried using wildcards in the file path to try and force a build of all project files. But it appears the file doesn’t support path matching :(.

So, the solution.

Simply make a copy of the ‘build’ task, and give it a different name. I tend to go for something useful like ‘build-’. Once copied, then update the path to be to the correct csproj.

Jump back over to the launch.json file, and simply update the preLaunchTask property to match the one you have just created in the tasks.json file.

Save everything, and run that debugger. Build and debug completely.

This might be common sense to some people, apologies if so! But it has just massively improved my VS code experience so thought sharing seemed warranted.

If there are any other cool little tips you have with VS Code, I’d love to hear them in the comments.