PowerShell 7.4 General Availability

As we come to towards the end of 2023, we are excited to announce the general availability of PowerShell 7.4! This release is built on .NET 8 and similarly, is our latest Long Term Support (LTS) release supported for 3 years.

We want to thank our community and many contributors for their invaluable help identifying issues, engaging in discussions in our repository, providing fixes and new features, and helping us ship a high quality release!

How do I get it?

Since PowerShell 7 is supported on Windows, Linux, and macOS, there are a variety of ways to get it. If you installed the previous PowerShell 7 stable release (7.3) via the Windows Store or MSI (and opted into Microsoft Update), you will be automatically updated to 7.4 GA.

What’s new?

This release continues to focus on enhancing the shell experience and addressing commonly reported customer and partner issues.

A detailed report of What’s New is available in our documentation or via the WhatsNew module.

Here are a few highlights:

PSResourceGet 1.0

This release includes PSResourceGet, which itself was made generally available earlier this year. PSResourceGet replaces PowerShellGet (although the two work side-by-side for legacy scripts) and where we will invest future enhancements to the PowerShell module ecosystem. This release focuses on a new codebase that is more maintainable and also provides better performance. In addition, this module uses a different set of cmdlets to allow for breaking changes that provide a more intuitive user experience.

PSReadLine 2.3

This release includes the latest PSReadLine release that contains a number of enhancements and bug fixes.

New stable features

The PowerShell Committee reviewed the experimental features we’ve had in the preview releases along with community feedback (issues) and telemetry indicating the feature was used and not disabled and decided that the following features were ready to be deemed stable for this release:

• PSConstrainedAuditLogging This feature enables PowerShell 7 to adhere to WDAC Audit mode and log events into the Windows Event Log. In this mode, PowerShell runs scripts in Full Language Mode, but logs events if there would be a difference in behavior in System Lockdown mode. This makes it easier for administrators to deploy PowerShell 7 in environments that have System Lockdown mode enabled by understanding what scripts would need to be modified to run in that mode.
• PSCustomTableHeaderLabelDecoration A common feedback from users is that with objects rendered as tables, it was not clear when a header label was not a property of the object. For example, when using Get-Process, you’ll see a column with the header CPU(s) to indicate the amount of cpu seconds used by that process. However, if you tried to access that property, you would find it’s actually called just CPU and the (s) was added to the header to indicate that it was in seconds. This new feature allows you to decorate the header label to make it clear that it is not a property of the object. The default decoration simply renders the header label in italics.
• PSWindowsNativeCommandArgPassing This is continuation of a feature we first added in 7.3. A major difference between Windows and non-Windows is how arguments are parsed particularly when quotes are involved. As more Open Source command-line tools are being used on Windows, we want to make sure that PowerShell can pass arguments to those tools in a way that works as expected. However, many legacy command-line tools on Windows do not handle arguments in the industry standard way. As such, a Windows mode for $PSNativeCommandArgumentPassing special cases some known tools to fallback to how it worked with Windows PowerShell while modern tools the new Standard mode. A Legacy mode is available for those that need to support legacy tools that do not work with the Windows mode.
• PSNativeCommandErrorActionPreference This is another continuation of a feature we first added in 7.3. This feature allows you to treat a non-zero exit code from a native command as an ErrorRecord that would come from a cmdlet. This allows you to set $ErrorActionPreference to Stop and have PowerShell stop execution whether a cmdlet had an error or a native command had a non-zero exit code. This simplifies scripts that previously would have to check $LASTEXITCODE after execution of a native command or wrap it in a helper function.
• PSNativeCommandPreserveBytePipe This feature allows you to preserve the byte stream when piping to or from a native command. Previously, all streams were converted to strings when piping to or from a native command and thus lost the original byte stream. This is useful for tools that expect binary input such as tar or zip.

There are still a number of experimental featues in this release pending additional user feedback before we can promote them to stable. For example, we continue to iterate on the Feedback Provider model as we get more feedback from users and partners who implement it.

Breaking changes

There are a few Breaking Changes in this release that you should be aware of although we expect them to be rare.

One that could affect some users is the new -ProgressAction common parameter. Similar to other common parameters, the new -ProgressAction parameter is automatically available to cmdlets and advanced functions. This parameter allows you to control how progress is reported for a cmdlet or advanced function call. Previously, you would have to set $ProgressPreference to SilentlyContinue to suppress progress and then restore it to its previous value.

What’s Next?

We will continue to focus on making PowerShell a great shell environment next year with PowerShell 7.5. As usual, we’ll continue to address issues and bugs reported by our community and partners as well as adopt the latest .NET 9 preview releases. Specific team investments will be discussed in a separate blog post early next year.

Thanks again to our community and partners for their continued support and feedback!