As of right now very simple checks are being used in order to check whether or not the process is running, this is done so the pesky error as described in #12 doesn't appear.

As #12 has stated; scenarios can occur where the process list still matches the filter, or maybe it sometimes doesn't match the filter when it should.

I therefore propose an extra configuration property processRegex when if passed, is used instead of the default process check. I don't expect this property to be used often, but for some users with edge cases it could be amazing - #12 woulnd't have been an issue if this was already implemented.

The Readme should also be updated with instructions on setting this up.

it seem the extension not waiting the dotnet watch restart

When I run the the extension everything works fine, but when I'm ready to stop I have to click the stop button twice before it actually stops.

I was able to reproduce this on your dotnet-watch-attach-sample repo and got the same behavior using only the necessary extensions:

Environment:

• Windows 11, version 22H2
• .NET 8.0.100

Let me know if there's anything else I need to provide you to help look into this. If I have time I'll try and take a look at the source code myself.

Watch Attach output when starting:

[WATCH ATTACH] [21:54:47] Attaching to weather.exe...
[WATCH ATTACH] [21:54:48] Successfully attached to weather.exe

Terminal output when starting:

 *  Executing task: C:\Program Files\dotnet\dotnet.exe watch run C:\Users\aowensby\OneDrive\Desktop\Projects\dotnet-watch-attach-sample/weather.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary 

dotnet watch 🔥 Hot reload enabled. For a list of supported edits, see https://aka.ms/dotnet/hot-reload.
  💡 Press "Ctrl + R" to restart.
dotnet watch 🔧 Building...
  Determining projects to restore...
  All projects are up-to-date for restore.
  weather -> C:\Users\aowensby\OneDrive\Desktop\Projects\dotnet-watch-attach-sample\bin\Debug\net6.0\weather.dll
dotnet watch 🚀 Started
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: https://localhost:7081
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5177
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: C:\Users\aowensby\OneDrive\Desktop\Projects\dotnet-watch-attach-sample\

Watch Attach output after first stop:

[WATCH ATTACH] [21:56:2] Child debug session terminated, restarting...

Terminal output after first stop:

dotnet watch ❌ Exited with error code -1
dotnet watch ⏳ Waiting for a file to change before restarting dotnet...

Watch Attach output after second stop:

[WATCH ATTACH] [21:56:40] Host debug session terminated, cleaning up...
[WATCH ATTACH] [21:56:40] A task was configured; terminating the task launched by Watch Attach

Sorry - it's taken so long to get back to you. I should point out, I'm on a Mac so we are not using .exe programs. The program EPBC.PSAS.dll is running after launching dotnetwatchattach.
I have verified this by starting dotnetwatchattach with program commented out, which gives the error. "Cannot find a program to debug".
However, with program not commented out and dotnetwatchattach running, my breakpoints become unbound.

Originally posted by @dfdumaresq in #4 (comment)

Brining this here from dotnet/vscode-csharp#4822 (comment)

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:

{
    "folders": [
        {
            // Create dotnet sample in /.../parentFolder with name "webapp1"
            "name": "Web App One",
            "path": "/.../parentFolder/webapp1"
        },
        {
            // Create dotnet sample in /.../parentFolder with name "webapp2"
            "name": "Web App Two",
            "path": "/.../parentFolder/webapp2"
        },
    ],
    "settings": {
    }
}

Then create launch and tasks files with similar content in both webapp1 and webapp2 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 from webapp2 using the dotnetwatchattach extension then it starts the task from webapp1 instead of webapp2.

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.

I'm trying to implement your solution in Orchard Core project. So far it's working but I'm getting this small issue when I try to start the launcher on the project. When I remove the "isBackground": true, it finds the proper problemMatcher but else it shows me this modal that requires me to click "debug anyway" every time. But everything works apart from that.

Let me know if you have an idea. Thanks.

See : OrchardCMS/OrchardCore#10881

I've added this to launch.json:

{
  "type": "dotnetwatchattach",
  "request": "launch",
  "name": ".NET Watch Attach",
  "args": { // Args to pass to coreclr attach
    "env": {
      "ASPNETCORE_ENVIRONMENT": "Development"
    },
    "project": "${workspaceFolder}/src/UI/FluxusApp/FluxusApp.csproj",
  },
  "task": "watchtask", // Label of watch task in tasks.json
  "program": "FluxusApp" // for windows Or "<startup-project-name>" for linux
}

and to tasks.json

{
  "label": "watchtask",
  "command": "dotnet",
  "type": "process",
   "linux": {
    "options": {
      "env": {
        // The FileSystemWatcher used by default wasnt working for me on linux, so I switched to the polling watcher.
        "DOTNET_USE_POLLING_FILE_WATCHER": "true"
      }
    }
  },
  "args": [
    "watch",
    "run",
    "${workspaceFolder}/src/UI/FluxusApp/FluxusApp.csproj",
    "/property:GenerateFullPaths=true",
    "/consoleloggerparameters:NoSummary"
  ],
  "problemMatcher": "$msCompile"
}

Yet I get the following error:
watch : Could not find a MSBuild project file in '/Users/josh/Code/RND/fcc'. Specify which project to use with the --project option.

Note on an M1 Mac, which seems to have added support in this extension

The powershell command used to get the name of the process only supports up to 24 characters which results in an issue with longer names such as testdotnetify.ScriptTag.exe

Hi will this work on linux?

I'm trying to use this extension on linux, but the debugger is not working

Was debugging issue #6 and it took me wayy too long to notice that the debugger was never attached. It might be nice to show the user that the process hasnt been found in a couple of seconds, this way we can give them a clue of why the configuration is not working.

We use launch.json to run dotnet against API's from different environments. So please see if you can implement the env: {} paramenter. It is not allowed in your current implementation.

This will be very helpful!

Thanks,
Dave

Just chirping in here: I also encounter this problem, additionally, every rebuild triggered through watch freezes the VSCode UI for about 30s, sometimes longer.

I have unfortunately no clue how to debug a VSCode extension, nor a setup. If someone knows of a good tutorial, I'd be open to give debugging and PR'ing a shot.

Originally posted by @hackathi in #16 (comment)

Turns out, this is unrelated – and I found the culprit just by looking at the sourcecode.
See, I use OhMyPosh to make powershell usable, but that means new powershell sessions take some time to load.

Solution is to use the -NoProfile switch in

PR incoming :)