Starting debug crashes PowerShell session if project is in onedrive folder

System Details Output

### VSCode version: 1.34.0 a622c65b2c713c890fcf4fbf07cf34049d5fe758 x64

### VSCode extensions:
ban.spellright@3.0.38
mohsen1.prettify-json@0.0.3
ms-azuretools.vscode-azurefunctions@0.17.1
ms-vscode.azure-account@0.8.4
ms-vscode.powershell@2019.5.0
ms-vscode.powershell-preview@2019.5.0
PeterJausovec.vscode-docker@0.6.2


### PSES version: 1.12.1.0

### PowerShell version:

Name                           Value
----                           -----
PSVersion                      5.1.17763.503
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.503
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3

OS is windows 10 1809 build

Issue Description

My WindowsPowerShell directory is on onedrive. C:\Users\james\onedrive\WindowsPowerShell has a symbolic link to C:\users\james\documents\WindowsPowerShell so profile etc is found.

Although I can use the directory under documents, VS-Code the likes to convert it to the canonical name so when I work on a project in my WindowsPowerShell directory it’s the one under onedrive.

If I have the debugger set for PowerShell interactive session, pressing F5 to start it crashes the interactive session with the message “The PowerShell session has terminated due to an error” … the stack trace in the log suggests a problem with the path.

If I copy the files from C:\Users\james\onedrive\WindowsPowerShell\modules\foo to C:\Users\james\temp\foo

Then all is well (so I have a work round).

Attached Logs

Editor services log attached. This has a stack trace from when the error occurs.

EditorServices.log

[rkeithhill]

Sigh… It seems like we need to do some redesign of how we manage client document representation in PSES. We have these test methods scattered about. It seems like a workspace should have a collection/dictionary of these documents - which I think today is a ScriptFile collection. That seems a bit too PS centric to me. Maybe it would be better to have a collection of EditorDocuments or TextDocument or something more inline with the LSP terms. Then move the workspace tests internal to that class and provide props like IsFile or IsFileScheme, UriScheme, that we could then use to determine if we can say, set breakpoints. If it’s not a FileScheme document then sorry dude, you don’t get breakpoints. Or maybe have a higher level of abstraction like IsDebuggable? Just thinking out loud here.

Sorry, don’t have time at the moment to look at the source so some of this may already be there but fundamentally, IIRC once we put something into a ScriptFile object, I think we may be assuming too much in the rest of the code base that there’s actually a file on disk. When as we’ve seen many times with VSCode, that is not the case.

[rjmholt]

Totally on your page there @rkeithhill.

I think this is worth patching in a small way for now and then we should come up with a better implementation going forward.

I’ll try and open a PR this week