Incorrect resource directories when run in VSCode Terminal

Prerequisites

Write a descriptive title.
Make sure you are able to repro it on the latest released version
Search the existing issues.

Steps to reproduce

VSCode 1.83.1 with PowerShell extension 2023.8.0, set to Windows PowerShell x64.
$PSVersionTable shows:
Name Value

PSVersion 5.1.19041.3633
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.3633
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

When running Install-PSResource it installs into the Documents\PowerShell\Modules directory instead of Documents\WindowsPowerShell\Modules

Expected behavior

Running PSResource cmdlets under Windows PowerShell should save to the WindowsPowerShell module/script direcory.


install-psresource -name exchangeonlinemanagement -scope CurrentUser


it should install to Documents\WindowsPowerShell\Modules\ExchangeOnlineManagement

Actual behavior

install-psresource -name exchangeonlinemanagement -scope CurrentUser


it *actually* installed to Documents\PowerShell\Modules\ExchangeOnlineManagement

Running the same line from powershell.exe or a Windows PowerShell tab in Terminal behaves as expected.

Error details

No response

Environment data

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Binary     1.0.0      Microsoft.PowerShell.PSResourceGet  {Find-PSResource, Get-InstalledPSResource, Get-PSResourceRepository, Get-PSScriptFileInfo...}

Key   : PSVersion
Value : 5.1.19041.3633
Name  : PSVersion


Key   : PSEdition
Value : Desktop
Name  : PSEdition


Key   : PSCompatibleVersions
Value : {1.0, 2.0, 3.0, 4.0...}
Name  : PSCompatibleVersions


Key   : BuildVersion
Value : 10.0.19041.3633
Name  : BuildVersion


Key   : CLRVersion
Value : 4.0.30319.42000
Name  : CLRVersion


Key   : WSManStackVersion
Value : 3.0
Name  : WSManStackVersion


Key   : PSRemotingProtocolVersion
Value : 2.3
Name  : PSRemotingProtocolVersion


Key   : SerializationVersion
Value : 1.1.0.1
Name  : SerializationVersion

Visuals

Terminal:

VS Code:

It looks like the issue is with utils.cs lines 985-990. If I read it correctly, it's looking at host.version and saying "if greater than 6.0, PowerShell, if less than, Windows PowerShell".
Since the VSCode PowerShell terminal returns the module version (2023.8.0) as it's host.version it's mis-interpreting it.

I think that'll be the same issue as #463 then

Andy Jordan (@andyleejordan)

Andy Jordan (@andyleejordan) do you know what PowerShell api we can call?

The linked issue had a note that linked to what PowerShellEditorServices does (if that helps): https://github.com/PowerShell/PowerShellEditorServices/blob/main/src/PowerShellEditorServices/Utility/VersionUtils.cs

Sydney Smith (@SydneyhSmith)

Sydney Smith (@SydneyhSmith) given the constraint that you've just got PSCmdlet...I'm not sure but am looking at it. Patrick Meinecke (@SeeminglyScience) any bright ideas? It has access to SessionState so there should be a good programmatic way to go about this but I'm not finding it quickly. I don't think I would want to invoke a command to do it...I mean maybe you're best off doing the reflection call like we do 🙃

no luck with a fix on this yet?

Just encountered this in Microsoft365DSC/Microsoft365DSC#7003. It is an issue in Utils.cs

PSResourceGet/src/code/Utils.cs

Lines 1164 to 1193 in 9c8bd26

    
           private readonly static Version PSVersion6 = new Version(6, 0); 
        
           private static void GetStandardPlatformPaths( 
        
               PSCmdlet psCmdlet, 
        
               out string localUserDir, 
        
               out string allUsersDir) 
        
           { 
        
               if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows)) 
        
               { 
        
                   string powerShellType = (psCmdlet.Host.Version >= PSVersion6) ? "PowerShell" : "WindowsPowerShell"; 
        
                   localUserDir = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), powerShellType); 
        
                   allUsersDir = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), powerShellType); 
        
               } 
        
               else 
        
               { 
        
                   // paths are the same for both Linux and macOS 
        
                   localUserDir = Path.Combine(GetHomeOrCreateTempHome(), ".local", "share", "powershell"); 
        
                   // Create the default data directory if it doesn't exist. 
        
                   if (!Directory.Exists(localUserDir)) 
        
                   { 
        
                       Directory.CreateDirectory(localUserDir); 
        
                   } 
        
                   allUsersDir = System.IO.Path.Combine("/usr", "local", "share", "powershell"); 
        
               } 
        
           } 
        
           public static bool GetIsWindowsPowerShell(PSCmdlet psCmdlet) 
        
           { 
        
               return psCmdlet.Host.Version < PSVersion6; 
        
           }

How about updating lines 1172 and 1192 to check the PSEdition variable. This returns 'Desktop' for Windows PowerShell 5.1 (or $null for previous versions of Windows PowerShell) and 'Core' for PowerShell Core.

Use the GetVariableValue method of PSCmdlet to get the variable.

The following code returns 'Desktop' under both Windows PowerShell 5.1 and the VS Code extension, and 'Core' under PowerShell 7 / VS Code extension:

function FunctionName {
   [cmdletBinding()]
    param($param)
    Write-Host $PSCmdlet.GetVariableValue('PSEdition')                                  
 } FunctionName

To me the PSEdition variable is a more solid way to check whether you're in Windows PowerShell or PowerShell Core instead of version numbers (because historically it's easy to screw up version numbers, and this bug is an example).

EDIT: The PowerShell blog team agree with me! https://devblogs.microsoft.com/scripting/powertip-identify-if-you-are-running-on-powershell-core/

However if you insist on using version numbers, this works too:

function FunctionName {
    [cmdletBinding()]
     param($param)
     Write-Host $PSCmdlet.GetVariableValue('PSVersionTable').PSVersion
  } FunctionName

Anyone able to review the attached pull request which hopefully should resolve this one?

Navigation Menu

Repository navigation

Incorrect resource directories when run in VSCode Terminal #1459

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	private readonly static Version PSVersion6 = new Version(6, 0);
	private static void GetStandardPlatformPaths(
	PSCmdlet psCmdlet,
	out string localUserDir,
	out string allUsersDir)
	{
	if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
	{
	string powerShellType = (psCmdlet.Host.Version >= PSVersion6) ? "PowerShell" : "WindowsPowerShell";
	localUserDir = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), powerShellType);
	allUsersDir = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), powerShellType);
	}
	else
	{
	// paths are the same for both Linux and macOS
	localUserDir = Path.Combine(GetHomeOrCreateTempHome(), ".local", "share", "powershell");
	// Create the default data directory if it doesn't exist.
	if (!Directory.Exists(localUserDir))
	{
	Directory.CreateDirectory(localUserDir);
	}

	allUsersDir = System.IO.Path.Combine("/usr", "local", "share", "powershell");
	}
	}

	public static bool GetIsWindowsPowerShell(PSCmdlet psCmdlet)
	{
	return psCmdlet.Host.Version < PSVersion6;
	}

Incorrect resource directories when run in VSCode Terminal #1459

Description

Prerequisites

Steps to reproduce

Expected behavior

Actual behavior

Error details

Environment data

Visuals

Activity

dsolodow commented on Oct 25, 2023

hbuckle commented on Oct 25, 2023

SydneyhSmith commented on Oct 30, 2023

dsolodow commented on Oct 30, 2023

andyleejordan commented on Oct 31, 2023

dsolodow commented on Jun 19, 2024

Borgquite commented on Mar 27, 2026

Borgquite commented on Apr 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions