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 usingGet-Process, you’ll see a column with the headerCPU(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 justCPUand 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, aWindowsmode for$PSNativeCommandArgumentPassingspecial cases some known tools to fallback to how
it worked with Windows PowerShell while modern tools the newStandardmode.
ALegacymode is available for those that need to support legacy tools that do not work with theWindowsmode.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$ErrorActionPreferencetoStopand 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$LASTEXITCODEafter 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 astarorzip.
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!
The post PowerShell 7.4 General Availability appeared first on PowerShell Team.