$psEditor.Workspace.OpenFile puts file name into all lower case.

[jhoneill]

System Details Output

### VSCode version: 1.49.0 e790b931385d72cf5669fcefc51cdf65990efa5d x64

### VSCode extensions:      
andyyaldoo.vscode-json@1.5.0
jock.svg@1.3.9
ms-azure-devops.azure-pipelines@1.174.2
ms-azuretools.vscode-azurefunctions@0.24.0
ms-dotnettools.csharp@1.23.2
ms-mssql.mssql@1.9.0
ms-python.python@2020.8.108011
ms-vscode-remote.remote-containers@0.140.1
ms-vscode-remote.remote-ssh@0.51.0
ms-vscode-remote.remote-ssh-edit@0.51.0
ms-vscode-remote.remote-wsl@0.44.5
ms-vscode-remote.vscode-remote-extensionpack@0.20.0
ms-vscode.azure-account@0.9.3
ms-vscode.powershell@2020.6.0
ms-vscode.powershell-preview@2020.7.0


### PSES version: 2.3.0.0

### PowerShell version:

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

This also appears with vs-code insiders and the 2020.9.0 extension ...

The issue is that the $psEditor.Workspace.OpenFile - which is called from various places - like PsEdit, changes the file name to lower case. This is usually just a cosmetic problem, but I have found a case were pester ran a script using its lower-cased name and the script failed because it tried to do a case sensitive replace on part of its own name.

[rjmholt]

@jhoneill can you give a particular example of where you've used this and what happened? There's not quite enough information here for me to work out what's going on and where the problem lies

[SeeminglyScience]

@rjmholt I think we store ScriptFile's as all lower case in an OrderedDictionary on Mac/Windows. I've ran into it too, easiest way to repro is:

# In PSIC 
New-Item Something.ps1 | Out-Null
psedit ./Something.ps1

And then look at the tab title.

I think it only happens when you haven't already opened the file at least once (so it's not in the workspace cache). I'm guessing the path is always lowercase in the request and if VSCode hasn't already cached some state for that file it'll take our word for it.

[rjmholt]

Sounds like our approach with surfacing the keys is wrong and they should be considered internal keys only, rather than something we expose somewhere.

Still, if I can get the example where it's caused a Pester issue in full detail, we'll be able to fix this in a much more reliable way than if I just guess where the issue is and claim it's solved.

[jhoneill]

Still, if I can get the example where it's caused a Pester issue in full detail, we'll be able to fix this in a much more reliable way than if I just guess where the issue is and claim it's solved.

It's working with the module from https://github.com/MethodsAndPractices/vsteam and the author has
a) A PS1 file for each command for each command function (e.g. Add-VSTeam.ps1)
b) A .Tests.PS1 file for each (e.g. Add-VSTeam.Tests.ps1) as the unit test for that command.
c) Lines in every unit-test to dot-source all the files needed for that command.

Describe "VSTeam" {
  BeforeAll {  
    $sut = (Split-Path -Leaf $PSCommandPath).Replace(".Tests.", ".")
    . "$PSScriptRoot/../../Source/Public/$sut"

So I

1. Open Add-VSTeam.Tests.ps1 from the PowerShell Window. It opens as add-vsteam.tests.ps1
   2.) I click Debug tests in the VSCode editor.

Pester then runs add-vsteam.tests.ps1 and $PSCommandPath).Replace(".Tests.", ".") does not replace tests, because this replace() is case sensitive. The script tires to DOT source a file with .tests and everything fails.

I know I could fix this by using -replace (or making other changes) but this bit of design isn't under my control. I can work round it by not opening from the command line ... and everywhere else - on windows at least - it is just a cosmetic thing. I don't know what happens if the underlying OS has a case sensitive file system.

[SydneyhSmith]

Thanks for the additional info @jhoneill

This issue was closed automatically as repro info was indicated as needed, but there has been no activity in over a week. Please feel free to reopen with any available information!

[jhoneill]

The bot auto closed this but the problem persists. I thought there was sufficient info to repro it ? Despite what the message, says it looks like one cannot reopen an issue which has has been closed by the bot.