`$PROFILE` variable has changed type and behavior

Prerequisites

• I have written a descriptive issue title.
• I have searched all 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.

Summary

Since updating to the latest preview, the $PROFILE variable in the Integrated Console has changed its type, from String to PSCustomObject.

Before:

PS>$PROFILE.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------     
True     True     String                                   System.Object

After:

PS>$PROFILE.GetType()

IsPublic IsSerial Name                                     BaseType     
-------- -------- ----                                     --------     
True     False    PSCustomObject                           System.Object

This change in type also changes the way the variable is coerced to other types, output to console etc possibly breaking any script that use this variable.

Before:

PS>$PROFILE

C:\Users\sburbano\Documents\PowerShell\Microsoft.VSCode_profile.ps1

After:

PS>$PROFILE

AllUsersAllHosts                          AllUsersCurrentHost                                        CurrentUserAllHosts                                CurrentUserCurrentHost
----------------                          -------------------                                        -------------------                                ----------------------
C:\Program Files\PowerShell\7\profile.ps1 C:\Program Files\PowerShell\7\Microsoft.VSCode_profile.ps1 C:\Users\sburbano\Documents\PowerShell\profile.ps1 C:\Users\sburbano\Documents\PowerShell\Microsoft.VSCode_profile.ps1

In my case, for example, custom theme loading in the profile has stopped working, because this function has stopped working.

PS>Get-ThemesLocation
Join-Path: C:\Users\sburbano\Documents\PowerShell\Modules\oh-my-posh\2.0.487\defaults.ps1:5:17
Line |
   5 |          return (Join-Path (Split-Path -Parent $PROFILE) $folderName)
     |                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find drive. A drive with the name '@{AllUsersAllHosts=C' does not exist.

Might be related to https://github.com/PowerShell/vscode-powershell/issues/3650

PowerShell Version

PS>$PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.1.5
PSEdition                      Core
GitCommitId                    7.1.5
OS                             Microsoft Windows 10.0.19042
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.62.0-insider
ff1e16eebb93af79fd6d7af1356c4003a120c563
x64

Extension Version

ms-vscode.powershell@2021.10.2

Steps to Reproduce

Compare the output of

PS>$PROFILE

in the PS Integrated Console and any other Powershell Console (regular pwsh.exe, Windows Terminal, …)

Visuals

No response

Logs

No response

[sburbano]

@SeeminglyScience Wow!! I see!

PS>$test = [psobject]"Some string"
PS>$test.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

PS>Add-Member -InputObject $test -NotePropertyName "SomeProperty" -NotePropertyValue "Some value"
PS>Get-Member -InputObject $test

   TypeName: System.String

Name                 MemberType            Definition
----                 ----------            ----------
[...]
SomeProperty         NoteProperty          string SomeProperty=Some value

PS is like a box of chocolates… 😄

[SeeminglyScience]

Yeah PSObject is kind of hard to inspect since a pretty significant amount of objects are going to be invisibly wrapped in PSObject many times throughout their lifetime. Really when you call .GetType(), that’s routed through the PSInvokeMemberBinder which controls method invocations are dynamically bound. For the most part, GetType() will never lie. Except with PSObjects when they’re wrapping other objects.

One thing that never lies (currently) though is -is. $test -is [psobject] will return true if the object is currently wrapped in a PSObject.

It gets very confusing but thankfully it doesn’t come up as a problem unless you look real close 😁