Open rrmistry opened 1 year ago
Thanks for opening this issue here - the extra details on your environment are also really helpful, as it helps me prioritize the issue.
Another work around would be to remove the taskname
config option from your launch configuration, and start the task manually (although I do understand if you are templating your tasks, that you are probably also templating your launch.json and it would be nice to have the task name in there)
Currently the plugin goes through all of the tasks, without taking your workspace into account; So I'd have to figure out a way to filter those tasks.
I will get back to you when I've gotten a proper solution - I'm fairly busy this week.
Brining this here from https://github.com/dotnet/vscode-csharp/issues/4822#issuecomment-1583658335
The Observation
When VS Code is used with multiple workspaces, then this extension tries to run the background dotnet watch task from an unexpected workspace.
How To Reproduce
To reproduce the issue we can start with a workspace file called
multiple-git-repos.code-workspace
with the contents:Then create
launch
andtasks
files with similar content in bothwebapp1
andwebapp2
workspaces (the only difference being that the project name is different).This means we will have two VS Code Tasks files with identical task names in both:
/.../parentFolder/webapp1/.vscode/tasks.json
and/.../parentFolder/webapp2/.vscode/tasks.json
Then open the multi-workspace session in VS Code via this workspace file.
Now if you try to debug
dotnetwatchattach
type launch config fromwebapp2
using the dotnetwatchattach extension then it starts the task fromwebapp1
instead ofwebapp2
.This behavior seems to be limited to only multi-workspace sessions within VS Code.
My workaround, for now, is to make the target task globally unique for the duration of debugging. But it is an inconvenience because we have many micro-services that are templated so this workaround is not ideal.