Announcing PowerShell 7.0

Joey Aiello

Joey

Today, we’re happy to announce the Generally Available (GA) release of PowerShell 7.0! Before anything else, we’d like to thank our many, many open-source contributors for making this release possible by submitting code, tests, documentation, and issue feedback. PowerShell 7 would not have been possible without your help.

What is PowerShell 7?

For those unfamiliar, PowerShell 7 is the latest major update to PowerShell, a cross-platform (Windows, Linux, and macOS) automation tool and configuration framework optimized for dealing with structured data (e.g. JSON, CSV, XML, etc.), REST APIs, and object models. PowerShell includes a command-line shell, object-oriented scripting language, and a set of tools for executing scripts/cmdlets and managing modules.

Three years ago, we announced PowerShell Core 6 as a completely new edition of PowerShell. Built on top of .NET Core, PowerShell Core introduced cross-platform support across Windows, macOS, and Linux, SSH-based PowerShell Remoting, massively improved support for REST and JSON, official Docker containers, and more. Additionally, it was the first release of PowerShell made under an open-source license (MIT), encouraging long-time PowerShell enthusiasts and complete newcomers alike to contribute directly to the source code, tests, and documentation.

After three successful releases of PowerShell Core, we couldn’t be more excited about PowerShell 7, the next chapter of PowerShell’s ongoing development. With PowerShell 7, in addition to the usual slew of new cmdlets/APIs and bug fixes, we’re introducing a number of new features, including:

  • Pipeline parallelization with ForEach-Object -Parallel
  • New operators:
    • Ternary operator: a ? b : c
    • Pipeline chain operators: || and &&
    • Null coalescing operators: ?? and ??=
  • A simplified and dynamic error view and Get-Error cmdlet for easier investigation of errors
  • A compatibility layer that enables users to import modules in an implicit Windows PowerShell session
  • Automatic new version notifications
  • The ability to invoke to invoke DSC resources directly from PowerShell 7 (experimental)

For a more complete list of features and fixes, check out the PowerShell 7.0 release notes.

The shift from PowerShell Core 6.x to 7.0 also marks our move from .NET Core 2.x to 3.1. .NET Core 3.1 brings back a host of .NET Framework APIs (especially on Windows), enabling significantly more backwards compatibility with existing Windows PowerShell modules. This includes many modules on Windows that require GUI functionality like Out-GridView and Show-Command, as well as many role management modules that ship as part of Windows. For more info, check out our module compatibility table showing off how you can the latest, up-to-date modules that work with PowerShell 7.

If you weren’t able to use PowerShell Core 6.x in the past because of module compatibility issues, this might be the first time you get to take advantage of some of the awesome features we already delivered since we started the Core project!

Awesome! How do I get PowerShell 7?

First, check out our install docs for Windows, macOS, or Linux. Depending on the version of your OS and preferred package format, there may be multiple installation methods.

If you already know what you’re doing, and you’re just looking for a binary package (whether it’s an MSI, ZIP, RPM, or something else), hop on over to our latest release tag on GitHub.

Additionally, you may want to use one of our many Docker container images. For more information on using those, check out our PowerShell-Docker repo.

What operating systems does PowerShell 7 support?

PowerShell 7 supports the following operating systems on x64, including:

  • Windows 7, 8.1, and 10
  • Windows Server 2008 R2, 2012, 2012 R2, 2016, and 2019
  • macOS 10.13+
  • Red Hat Enterprise Linux (RHEL) / CentOS 7+
  • Fedora 29+
  • Debian 9+
  • Ubuntu 16.04+
  • openSUSE 15+
  • Alpine Linux 3.8+

Additionally, we support ARM32 and ARM64 flavors of Debian and Ubuntu, as well as ARM64 Alpine Linux.

While not officially supported, the community has also provided packages for Arch and Kali Linux.

If you need support for a platform that wasn’t listed here, please file a distribution request on GitHub (though it should be noted that we’re ultimately limited by what’s supported by .NET Core 3.1).

Wait, what happened to PowerShell “Core”?

Much like .NET decided to do with .NET 5, we feel that PowerShell 7 marks the completion of our journey to maximize backwards compatibility with Windows PowerShell. To that end, we consider PowerShell 7 and beyond to be the one, true PowerShell going forward.

PowerShell 7 will still be noted with the edition “Core” in order to differentiate 6.x/7.x from Windows PowerShell, but in general, you will see it denoted as “PowerShell 7” going forward.

Which Microsoft products already support PowerShell 7?

Any module that is already supported by PowerShell Core 6.x is also supported in PowerShell 7, including:

On Windows, we’ve also added a -UseWindowsPowerShell switch to Import-Module to ease the transition to PowerShell 7 for those using still incompatible modules. This switch creates a proxy module in PowerShell 7 that uses a local Windows PowerShell process to implicitly run any cmdlets contained in that module. For more information on this functionality, check out the Import-Module documentation.

For those modules still incompatible, we’re working with a number of teams to add native PowerShell 7 support, including Microsoft Graph, Office 365, and more.

Azure Cloud Shell has already been updated to use PowerShell 7, and others like the .NET Core SDK Docker container images and Azure Functions will be updated soon.

How is PowerShell 7 officially supported by Microsoft?

As with PowerShell Core, PowerShell 7 is a supported product for a wide range of customers with existing Microsoft support agreements.

With PowerShell 7, we’re moving to a support lifecycle whereby we match the lifecycle of the underlying .NET runtime that we distribute as part of PowerShell. This means that PowerShell 7.0 is a long-term servicing (LTS) release that will be supported for approximately 3 years from December 3, 2019 (the release date of .NET Core 3.1).

You can find more info about PowerShell’s support lifecycle at https://aka.ms/pslifecycle

What’s next for PowerShell?

We’re already hard at work on PowerShell 7.1, and you should expect its first preview soon, chock full of new features and bugfixes that didn’t quite make it into 7.0. Stay tuned for a more in-depth roadmap blog outlining our current investigations and desires for 7.1.

As noted above, we’re also moving to an annual release cadence in order to align better with .NET releases and their support lifecycle (with previews continuing to release roughly every month).

How can I give feedback on PowerShell 7?

For most issues directly related to PowerShell 7, start by filing an issue on the main PowerShell repository. For issues related to specific modules (e.g. PSReadline or PowerShellGet), make sure to file in the appropriate repository.

Thanks again!

Much appreciation to everyone involved in this release, from multi-time contributors all the way to those of you keeping up with our preview releases. We couldn’t have done it without you!

Joey Aiello PM, PowerShell

31 comments

Comments are closed. Login to edit/delete your existing comments

  • Niclas Eriksson
    Niclas Eriksson

    Kind of confused about this. Blog says “core” is new standard (and no longer named core) so what version will ship by default with Windows? I’m not that interested in Powershell on systems where bash is a native choice but need to “get stuff done” on Windows. Honestly this seems to get in the way of that goal. Migrating scripts isn’t exactly a value adder and the wording “maximize backwards compatibility” reads like “there will be undefined breaking changes” to me..

  • Avatar
    Nachum Ella

    What about DSC? Is there anything new to the platform? Did the DSC capabilities and keywords got transferred to PowerShell 7? What about the LCM?
    Should we even still invest in DSC?

  • Avatar
    Ajay Mehta

    Has PowerShell 7.0 introduced a change to PSModulePath environment variable?

    I now see it contains:

    C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
    ~\Documents\WindowsPowerShell\\Modules\

    This was not the case with PowerShell 6.2.4. I don’t have WindowsCompatibility module imported.

  • Avatar
    Fleet Command

    Wow! Great news! I’ve got a lot of questions though. 😊

    First, is PowerShell 7 going to be bundled with the next version of Windows 10 or Windows Server?

    Second, now that PowerShell 7 is released, will your documentation update pipeline be fixed?

    What is “PowerShell-7.0.0-win-fxdependentWinDesktop.zip”?

    The Microsoft Docs web page mentions .msix packages. What are they? Where can I get them? What’s the benefit of using them?

  • Avatar
    Vector BCO

    Is it expected that my build in PS 5.1 on Windows 10 have version 5.1.18362.628, but PS 7.0 display $PSVersionTable.PSCompatibleVersions compatible version 5.1.10032.0 (lower than build-in)?

  • Avatar
    Jefferson Motta

    LTS should be 20 years support. if I can desing software, in 1994 – that runned till 2015 that I know -, why a super mega company like Microsoft can’t do it?

  • Avatar
    Freddy Grande

    Is the omission of an MSIX package for ARM64 on purpose? Previous releases had them and made it easy to install on ARM64 devices like the Surface Pro X. What would I be missing by copying and pasting the .zip package other than prerequisite checks?