Yeah, it’s weird. The reason why that’s happening is because the debugger is attempting to execute your plugin like a standalone application, which won’t work since it’s just a DLL. There are two ways of setting up plugin debugging in VS that I know of:
First way: You need to start up a host (Ableton, Reaper, whatever) and attach the VS debugger to it, then load an instance of your plugin. VS should be able to load the debug symbols for your plugin automatically and then you’ll be able to set breakpoints in your plugin code as it’s executing.
So instead of clicking “Local Windows Debugger”, start up your host, then in VS go to Debug -> Attach to Process and pick your host application. Now set a breakpoint somewhere in your plugin source in the VS code editor. When you load your plugin in the host, so long as you set the breakpoint somewhere it will be hit (i.e. processor’s constructor or prepareToPlay or processBlock, etc) the program should pause and you know you’re debugging!
Second way: This is my preferred way, it’s basically an automatic way of doing the method above that allows you to use the “Local Windows Debugger” button. Right click on your plugin project in VS (the first item under the solution in the browser) and open properties. Go to “Debugging”, and set “Command” to be a path to your host’s .exe. In some cases (like the JUCE demo plugin host I’m pretty sure) you can also set a file for the host to open automatically on launch by specifying it in the “Command Arguments” field. That way if you want you can auto-open some host project that has your plugin and some test audio in it or something which helps a lot with rapid iteration.
You should now be able to press “Local Windows Debugger” and it will automatically open your host and attach the debugger to it, allowing you to load your plugin and debug it.
Hopefully this helps!