Migrate to PowerShell Core as the main command runner

[Starz0r]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

PowerShell 5 is almost a decade old now, and has seen almost no support, updates, or upgrades that would make it more usable over using PowerShell Core. PS 5 is at it's end of life already, and I think it's time to move to PS Core, which will likely be default in the coming Windows versions.

Describe The Solution. Why is it needed?

The solution is simple as installing along side Chocolatey, or repackaging it with it.

But why use PowerShell Core, and not the PowerShell installed with the system? Aside from outdated dependencies, it will eventually get changed. On top of being faster, and more maintained, it has a number of different QoLs that a Package Maintainer like me would like to use. I've been burned too many times running a script locally thinking it will work, only to realize "Oops! Forgot concatenating a Path Object and a String isn't possible in PS 5".

Additional Context

Having PowerShell Core 6 installed along side Chocolatey would mean you could use PS 5 by default, and packages can opt into using a new runner. I find this would be the best migration path available to us. This way we don't immediately remove PS 5 support, but deprecate it, and at a later date, can decide to remove it entirely.

Related Issues

No response

[TheCakeIsNaOH]

PS 5 is at it's end of life already, and I think it's time to move to PS Core, which will likely be default in the coming Windows versions.

PowerShell v5.1 is supported for as long as the OS it is shipped on is supported. It was shipped with Server 2025, so PowerShell v5.1 is not going to go EOL until at least 2034
https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2025

I still do think that the PowerShell core improvements are worthwhile, just that EOL of v5.1 is not a factor.

The solution is simple as installing along side Chocolatey, or repackaging it with it.

Chocolatey CLI uses it's own PowerShell host (e.g. not using PowerShell.exe, but setting up its own stuff with the system management automation dll). This allows things like the timeout behavior when prompting the user. My understanding is also that some of the licensed edition features need the custom PowerShell host to function.

This means that to upgrade to PowerShell core without a major rework of how scripts are run, an upgrade would be needed of Chocolatey CLI, Chocolatey GUI, and the licensed editions all to Dotnet core, because of the way the new PowerShell core host .dll files work. This also means that Windows PowerShell (v5.1) can't be used alongside PowerShell core, it's going to be a hard cutover. Additionally, each version of Dotnet has a specific version of the PowerShell core dll files it supports, so the version of PowerShell core used will update in step with the version of Dotnet used.

There is already an issue for the upgrade to dotnet core, when I looked at some of this: #2173
I also have branch where I started migrating Chocolatey CLI to dotnet 8: https://github.com/TheCakeIsNaOH/choco/tree/dotnet-8

It may be possible to break out the package script running into a separate .exe file, which choco.exe would call, which would then run the appropriate script. That way, the PowerShell core upgrade could be decoupled from the overall upgrade to Dotnet core. However, this may not be for the licensed edition, which would nix the idea.