Hi Dan,
I asked my ChatGPT and the answer looks pretty good to me (though my own VS Code expertise is rather flimsy).
Below is what it offered. If you’re still stuck, please write back and I can help further.
-Govert
====================================
What you’re seeing is normal for VS Code: launch.json’s preLaunchTask is only used when you start debugging, and the default “build” you’re getting is usually coming from the C# extension’s built-in build command, not necessarily the tasks.json task you wrote.
So there usually isn’t a “hidden task” file—there’s a built-in build action (OmniSharp / C# Dev Kit depending on what you installed) that runs something like the command you pasted.
1) Confirm what VS Code is building (and whether it’s your task)
A. When you press Ctrl+Shift+B
That runs the default build task (if you have one). If you don’t, VS Code may prompt you, or an extension may supply a default.
Open .vscode/tasks.json and make sure you actually have:
Example:
{
"version": "2.0.0",
"tasks": [
{
"label": "build (Debug)",
"type": "process",
"command": "dotnet",
"args": [
"build",
"${workspaceFolder}/MyProject.sln",
"/p:GenerateFullPaths=true",
"/p:Configuration=Debug",
"/p:Platform=Any CPU",
"/consoleloggerparameters:NoSummary"
],
"problemMatcher": "$msCompile",
"group": { "kind": "build", "isDefault": true }
}
]
}
If you don’t have "group": { "kind": "build", "isDefault": true }, VS Code might not use it when you do a “build”.
B. When you press F5 (debug)
That runs:
If preLaunchTask is set to "debug" but you don’t have a task with "label": "debug", VS Code usually shows an error like “could not find the task”.
So: check launch.json and ensure the preLaunchTask string exactly equals a tasks.json "label".
Example:
{
"configurations": [
{
"name": "Debug Excel",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build (Debug)"
}
]
}
2) Build Release from the terminal (quickest, zero VS Code plumbing)
From the workspace root:
dotnet build .\MyProject.sln -c Release
If you also want to force platform:
dotnet build .\MyProject.sln -c Release -p:Platform="Any CPU"
That’s the simplest reliable way to confirm Release works before wiring tasks.
3) Add a Release build task in tasks.json
Add a second task:
{
"label": "build (Release)",
"type": "process",
"command": "dotnet",
"args": [
"build",
"${workspaceFolder}/MyProject.sln",
"/p:GenerateFullPaths=true",
"/p:Configuration=Release",
"/p:Platform=Any CPU",
"/consoleloggerparameters:NoSummary"
],
"problemMatcher": "$msCompile",
"group": "build"
}
Now you can run:
4) If you want F5 to still debug, but you want “Release” sometimes
Two common patterns:
Pattern A: Debug always uses Debug build (recommended)
Keep preLaunchTask = "build (Debug)".
Use the Release task only when packaging / publishing.
Pattern B: Add a second launch configuration for Release
You typically don’t debug Release, but sometimes you want to launch Excel with a Release-built add-in.
{
"name": "Launch Excel (Release build)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build (Release)"
--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to exceldna+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/exceldna/bebd2cac-57b9-44cb-a503-c78b2430c70en%40googlegroups.com.