@rkeithhill and where would you show that message in the breakpoints view without introducing too much clutter? I suggest to show it on hover. What do you think?

@isidorn Yeah but I was also thinking that the Breakpoints viewlet could show a glyph indicating there is a problem with the breakpoint and then provide a tooltip (hover as you put it) to display the message e.g.:

But if you don't like the extra glyph - maybe the checkbox is shown in an indeterminate state? Or perhaps the breakpoint text is red or perhaps the text uses strike-through. You just need some sort of indication to draw their attention and then the hover would explain why the breakpoint wasn't set.

Now if the breakpoint is unverified we show the message on hover and we show the whole breakpoint grayed out - same as how we show all breakpoints when you deactivate them.
Let me know if you like it

@isidorn I'm not able to verify this fix in the latest alpha. With the breakpoint set in the now nonexistent original DebugTest.ps1 I am also not able to debug other files.

@vsccarl the issue with not being able to debug with the PowerShell is a known issue with the PowerShell extension. We should have a fixed version (0.6.0) released in a week or so. For now, you can work around this by setting a breakpoint in your program and then you should be able to debug.

That said I'm not seeing this issue as fixed on my machine at work with today's alpha build. I will need to check later tonight on my home dev machine with daily 0.6.0 PS extension bits.

@isidorn OK, checked the PSES ext daily bits and I still don't see the breakpoint grayed out and there is no hover tip. Now I am checking this in the BREAKPOINTS viewlet which I assume is what you're talking about, right? Because the breakpoints in question are for files that no longer exist so it would be impossible to see the grayed out breakpoint in the editor window. :-)

@rkeithhill yeah, it is in the breakpoints veiwlet :) Today is last game of endgame, which means we only look at critical bugs, thus I will investigate why is this not fixed on monday, though that means it will only be available in our may release.
I myself have seen this working in action. Are you sure the adapter sends verified false for these breakpoitns?

Yes we set verified to false. Is there anything else in this response message that might be wrong?

Log file snippet from debug session:

    WRITE MESSAGE:

    {
      "type": "response",
      "request_seq": "3",
      "command": "setBreakpoints",
      "success": true,
      "body": {
        "breakpoints": [
          {
            "verified": false,
            "message": "Source does not exist, breakpoint not set.",
            "source": "c:\\Users\\Keith\\.vscode-alpha\\extensions\\ms-vscode.PowerShell-0.5.0\\examples\\DebugTest.ps1",
            "line": 18,
            "column": null
          }
        ]
      }
    }

Found the issue - now it should work

@isidorn I've confirmed the fix. Thanks!