[pscustomobject] type accelerator does not work in 7.4.0

[shivtorov]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

1. Open PowerShell 7.4.0 tab in Windows Terminal
2. cast a hashtable to pscustomobject type accelerator

Expected results: a new object created
Actual results: nothing = no new object, no errors, no hashtable

Expected behavior

PS> [pscustomobject]@{one=1; two=2}

one two
--- ---
  1   2

Actual behavior

PS> [pscustomobject]@{one=1; two=2}

Error details

No response

Environment data

PS> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.0
PSEdition                      Core
GitCommitId                    7.4.0
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1, 6.0, 7.0}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

[trackd]

that's pretty strange, your example works for me on 7.4.0.

Could you try and temporarily disable Constrained Language Audit Mode, and see if that makes a difference?
I'm not too familiar with it, but it's an obvious difference.

PS > [pscustomobject]@{one = 1; two = 2 }
one two
--- ---
  1   2

PS > ([pscustomobject]@{one = 1; two = 2 }).Gettype().Name
PSCustomObject

PS > ([pscustomobject]@{one = 1; two = 2 }).One.Gettype().Name
Int32

PS > $ht = @{}
PS > $ht.add('one',1)
PS > $ht.add('two',2)
PS > [PSCustomObject]$ht
two one
--- ---
  2   1

PS > $PSVersionTable

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

[B-Art]

It does just work for me:
The only remark I have is that PSCompatibleVersions is displayed trackd shows. {1.0, 2.0, 3.0, 4.0…}
Not showing like {1.0, 2.0, 3.0, 4.0, 5.0, 5.1, 6.0, 7.0}
But

$PSVersionTable.PSCompatibleVersions

Shows:

Major  Minor  Build  Revision
-----  -----  -----  --------
1      0      -1     -1
2      0      -1     -1
3      0      -1     -1
4      0      -1     -1
5      0      -1     -1
5      1      -1     -1
6      0      -1     -1
7      0      -1     -1

[B-Art]

Also check how (in what way) you did install pwsh 7.4:
https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.4

Installing PowerShell on Windows - PowerShell

Information about installing PowerShell on Windows

[HumanEquivalentUnit]

It works for me as well; do you get anything if you run this, to see if there is an output and it's just being hidden on your terminal somehow:

PS> $x = [pscustomobject]@{one=1; two=2}
PS> $x | Get-Member

Or these, to check if the type accelerator is working?

PS C:\> [pscustomobject]

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

PS C:\> [pscustomobject].FullName
System.Management.Automation.PSObject

PS C:\> [System.Management.Automation.PSCustomObject]

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

[shivtorov]

yeah, that's a weird issue.
I checked the same on a different Windows 11 23h2 PC and everything works as expected there.
I uninstalled and manually reinstalled 7.4.0 version using MSI (x64) installer on the affected PC - issue is still there.

The OS on the affected PC is freshly installed from ISO a week ago.
The only thing that is different on this PC is that it is managed by company policies pushed via Microsoft Intune.
One of these policies enabled "Constrained Language Audit Mode" (whatever it means).
I guess that this "Constrained Language Audit Mode" is breaking [pscustomobject].

I downloaded x64 ZIP versions 7.4.0 and 7.3.10 to test without installation - results are:

I have a workaround for this problem for me - I will just use a different PC/VM for executing scripts using [pscustomobject] type accelerator.

[shivtorov]

The issue is affecting all corporate laptops in our company.
It turned out that somehow corporate policies activate ConstrainedLanguage mode, but only v7.4.0
Strangely, the policies don't affect previous versions (such as 7.3.10)
My fix is to manually switch to FullLanguage mode.

[mcqueene]

The OS on the affected PC is freshly installed from ISO a week ago. The only thing that is different on this PC is that it is managed by company policies pushed via Microsoft Intune. One of these policies enabled "Constrained Language Audit Mode" (whatever it means). I guess that this "Constrained Language Audit Mode" is breaking [pscustomobject].

I can confirm the same issue with Constrained Language Audit Mode breaking [pscustomobject]

[mklement0]

Update: See next comment.

---

@shivtorov, note that [System.Management.Automation.PSCustomObject] @{ foo = 1 } never worked - only [pscustomobject] @{ foo = 1 } does, because - confusingly - these aren't the same types ([pscustomobject] is the same type as [psobject], i.e. [System.Management.Automation.PSObject], but the syntactic sugar only works with [pscustomobject]:

• Why is [pscustomobject] the same as [psobject], even though a distinct [System.Management.Automation.PSCustomObject] type exists? #4344

[mklement0]

On further reflection, I think there are two separate bugs:

• System lockdown / WDAC: Use of new audit-only mode prevents use of [pscustomobject] literals, behaves as if ConstrainedLanguage mode were in effect #20768
• ConstrainedLanguage mode: [pscustomobject] literals cannot be used, even though the type is white-listed, and an equivalent New-Object call succeeds #20767