Update Get-WingetCmd.ps1

[AndrewDemski-ad-gmail-com]

Proposed Changes

Missing failsafe when winget does not exist in system context (trigger for fallback to instance in the user context). Addendum to logic changed in PR #789

Related Issues

#789

[KnifMelti]

-ErrorAction Stop doesn't work for me, -ErrorAction Break does...
[EDIT] Even if -ErrorAction Break doesn't exist in PS (so they say)...

Got an explanation from Claude:

In PowerShell, -ErrorAction Break actually does work differently in a Try block compared to other contexts. In a Try block, Break allows you to exit the current loop or script block without terminating the entire script, which behaves differently from Stop.

In your specific example:

$WingetInfo = (Get-Item -Path $ps -ErrorAction Break).VersionInfo | Sort-Object -Property FileVersionRaw -Descending | Select-Object -First 1

Break here will skip the current iteration or exit the current block if an error occurs, which can be more graceful than Stop in some scenarios. This explains why you're getting the correct result with Break where Stop fails.

It's a nuanced behavior that isn't always consistent across all PowerShell contexts, but in Try blocks and certain loop structures, Break can provide more flexible error handling.

[KnifMelti]

-ErrorAction Stop doesn't work for me, -ErrorAction Break does... [EDIT] Even if -ErrorAction Break doesn't exist in PS (so they say)...

But; with -EA Break that works in user context, it seems not to be working in SYSTEM context.
There only your original or -EA Stop works.
I'm lost.

[KnifMelti]

This works for both SYSTEM/User (your original without -EA):

    try {
        #Get Admin Context Winget Location
        $WingetInfo = (Get-Item -Path $ps).VersionInfo | Sort-Object -Property FileVersionRaw -Descending | Select-Object -First 1;
            if ($null -ne $WingetInfo) {
                $WingetCmd = $WingetInfo.FileName
            } else {
                throw "WingetInfo is null"
            }
        }

Or:

    if ($WingetInfo -and $WingetInfo.FileName) {
        $WingetCmd = $WingetInfo.FileName
    } else {
        throw "WingetInfo is null or invalid"
    }

Or revert to @Romanitho original...

DeepSeek said:
Permission Management in Windows
If $ps is a path that only the SYSTEM account has permission to access, Get-Item will fail, but it may return $null instead of throwing an error. This is due to how Windows handles access control and how PowerShell interacts with the file system.