Get-PackageProvider is not recognized when running builds as non-administrator

[corbob]

Checklist

• I confirm there are no unresolved issues reported on the Chocolatey Status page.
• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my problem.
• I have verified this is not an issue for a specific package.
• I have verified this issue is not security related.
• I confirm I am using official, and not unofficial, or modified, Chocolatey products.

What You Are Seeing?

Trying to run the build on Chocolatey CLI in a non-administrative terminal, receive the error: The term 'Get-PackageProvider' is not recognized as the name of a cmdlet, function, script file, or operable program.

What is Expected?

The build should finish.

How Did You Get This To Happen?

1. Clone down https://github.com/chocolatey/choco
2. Run build.bat in the cloned down repo as a non-admin user.
3. Receive the error

System Details

• Operating System: Windows 10
• Windows PowerShell version: 5.1
• Chocolatey CLI Version: N/A
• Chocolatey Licensed Extension version: N/A
• Chocolatey License type: N/A
• Terminal/Emulator: N/A

Installed Packages

N/A

Output Log

See screenshot above.

Additional Context

Workaround(s):

• Run the build with --shouldRunPSScriptAnalyzer=false if you don't need the PSScriptAnalyzer output.
• Run the commands here: Get-PackageProvider is not recognized when running builds as non-administrator #158 (comment)

This may stem from the fix for #130.

[corbob]

Ok, so this seems to maybe have started happening even if you are an administrator... I have found a workaround for the Chocolatey Developer VM, that may work for others.

Basically you can short circuit the script by running the following in an elevated Windows PowerShell session:

# Determine where `ConvertToSARIF` and `PSScriptAnalyzer` are installed if they are already installed.
Get-Module -List ConvertToSARIF, PSScriptAnalyzer
# If it is installed to the local user, you need to uninstall it:
Uninstall-Module ConvertToSARIF
Uninstall-Module PSScriptAnalyzer
# Install the module to AllUsers scope
Install-Module ConvertToSARIF -requiredversion 1.0.0 -Scope AllUsers
# Install PSScriptAnalyzer to AllUsers scope
Install-Module PSScriptAnalyzer -RequiredVersion 1.21.0 -Scope AllUsers

In my testing, after running this, then the error no longer occurs. It is possible that there are versions of PowerShell modules in play that have been updated and changed some of these things. We will want to identify what versions work for these scripts and pin to them if possible.

[gep13]

Should the above be done in both PowerShell and Windows PowerShell?

[corbob]

In my testing it was only needed in Windows PowerShell. From what I can tell, the Cake.PowerShell addin that's used launches powershell.exe. I'm also not entirely sure what is going on, as on another system both PSSA and ConvertToSARIF were installed at the user level, and this issue didn't occur 🤦‍♂

[corbob]

I have an update to this that I've encountered while testing out the new VMs: If you run this entirely from Windows PowerShell, then you only need to run elevated the first time, then every other run works just fine. If however you try to run from within PowerShell 7.4.6 (and probably other versions), you will need to perform the workaround above. This appears to be related to the PSModulePath populated by pwsh not including the Windows PowerShell Current User modules in the path. A workaround from pwsh without doing the above which effectively moves the modules to the machine path is to run: $env:psmodulepath = [System.Environment]::GetEnvironmentVariable('psmodulepath', 'machine') and then run the build script. We should probably do this in the recipe to reset the PSModulePath to the stored path instead of the one that the calling process had built.