Can't debug when using PowerShell 7.4

[PrzemyslawKlys]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

It seems that VSCode doesn't stop on breakpoints when debugging in PS 7.4

PowerShell Version

Name                           Value
----                           -----
PSVersion                      7.4.0-preview.4
PSEdition                      Core
GitCommitId                    7.4.0-preview.4
OS                             Microsoft Windows 10.0.22621
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0.}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

1.80.1
x64

Extension Version

ms-vscode.powershell@2023.6.0

Steps to Reproduce

1. Create empty file
2. Add some code

Write-Host "Test 1"

Write-Host "Test 2"

3. Set breakpoint

4. Press F5

5. Notice it doesn't stop

Visuals

Logs

No response

[sba923]

Confirmed here with PowerShell 7.4.0-preview.4 on Windows 10, with v2023.6.0 of the extension.

[andyleejordan]

Thanks, am looking at this with high priority.

[andyleejordan]

Yup, reproduces locally. Going to start testing versions backwards to see when it first breaks.

[andyleejordan]

Whelp, works in preview.3 and not preview.4 so at least that's pretty narrow!

[andyleejordan]

"Narrow" as I look at the diff...my current guess is from PowerShell/PowerShell#14953 but I need to figure out exactly what.

[fflaten]

I can only reproduce on Windows, not Ubuntu. What about MacOS?

[fflaten]

Looks like a perfect storm caused by two bugs:

• Change to case-sensitive path comparison in PowerShell, see Regression in debugger broke setting breakpoints in VS Code PowerShell extension PowerShell#20044 (comment)
• Extension registering breakpoint with lowercase driveletter. This seems to be known already, see https://github.com/PowerShell/PowerShellEditorServices/blob/bfe334df7e4bdd4b92c5c0319655e40444e185ff/test/PowerShellEditorServices.Test/Debugging/DebugServiceTests.cs#L140-L141

# breakpoint set in vscode
> Get-PSBreakpoint | % Script 
c:\Users\Frode\Desktop\Demo\HelperModule.psm1

# reference - notice driveletter
> dir .\HelperModule.psm1 | % fullname
C:\Users\Frode\Desktop\Demo\HelperModule.psm1

[andyleejordan]

@fflaten I can at least say that the server is registering with that driver letter being lowercase because it's literally coming across the wire that way (that is, in the SetBreakpointsArguments request of the SetBreakpointsResponse handler with OmniSharp). Not sure if it's something O# is doing, or if it's coming from the client like that. If I can fix that, theoretically this issue is "solved" (though I still think we should fix the behavioral regression in PowerShell until we do it intentionally).

[andyleejordan]

Uhh actually, more info! I see the same behavior in the logs of the C# extension (also built on top of O#) where the drive letter is being lower-cased for every LSP request with a path. So it's definitely an O# thing. Grr.

[fflaten]

Maybe intentional to align with VSCode API? Uri.fspath also lowercases it (source)

fsPath: string

The string representing the corresponding file system path of this Uri.

Will handle UNC paths and normalize windows drive letters to lower-case. Also uses the platform specific path separator.

[andyleejordan]

@fflaten yup, that was exactly it! Ha, just saw this and figured out the same thing from a different investigation.