PowerShell 7 Roadmap
Last month we announced that PowerShell 7 will be the next release of PowerShell.
Here I will provide more details of areas we’ll be investing in for the PowerShell 7 release.
When will I get it?!
Today, we’re releasing our first preview of PowerShell 7. Keeping with our monthly cadence, expect new preview releases approximately every month.
This first preview contains some of the changes that didn’t make it in time for the 6.2 GA release, and marks our move to .NET Core 3.0. For more details on what’s new, check out our changelog on GitHub.
As mentioned in the PowerShell 7 announcement blog, we will be changing the support life-cycle to align with .NET Core. This means that we expect PowerShell 7 to be generally available (GA) about a month after .NET Core 3.0 GA.
.NET Core 3.0
The biggest immediate change is moving to .NET Core 3.0 (from .NET Core 2.1). Not only are there significant performance improvements, but many new APIs are available including WPF and WinForms (Windows only, though!).
This means that (eventually) we can bring back Out-GridView.
Windows Compatibility
A big focus of PowerShell 7 is making it a viable replacement for Windows PowerShell 5.1. This means it must have near parity with Windows PowerShell in terms of compatibility with modules that ship with Windows.
The PowerShell Team will be working with Windows teams to validate and update their modules to work with PowerShell 7. This also means that to use PowerShell 7 with the breadth of Windows PowerShell modules, you will need to be using the latest builds of Windows 10 (and equivalent Windows Server).
Feature Investigations
We are looking at investing in three specific feature areas. Expect RFCs (Request For Comments specifications) to be published on how we intend to implement these features and the scope of the problem we intended to solve. Feedback is greatly appreciated!
Simplify Secure Credentials Management
Whether you are using PowerShell to automate resources in the cloud, local resources on premise, or a hybrid, you will generally need to have different credentials to access different resources.
The best practice is to never put credentials within your script. So we intend to introduce a way to securely use credentials from a local or remote based credential store.
Logging Off the Box
Part of the security of PowerShell is that it can log everything. However, logging today is purely local onto the machine. For each OS, there are ways to forward those events to a remote system, but it requires different configurations per OS.
We want to introduce a way to easily configure PowerShell through policy to automatically send the logs to a remote target regardless of the OS.
New Version Notification
Looking at our PowerBI dashboard, we see a large number of instances using older versions (some of which are no longer supported). It is important to inform our customers if there is a newer version available that may have security fixes so we need a way to inform the user that a newer version is available politely.
There is already a RFC published for this feature. Please take a look and provide us feedback!
GitHub Issues
We have a number of GitHub issues marked to be considered to be addressed for PowerShell 7. Although we would like to fix everything, we do have limited resources so not every issue marked for consideration will be fixed.
Popular Requested Features
There are a number of requested features we’d like to address in PowerShell 7. Some of these may show up as experimental features so that we can get feedback before we lock in the design.
This list is larger than what we will be able to fix, but these are the ones we’d like to investigate:
- Improve the default formatting of errors
- Ubiquitous -OnError {ScriptBlock} parameter
- Control operators for chaining commands
- Ternary conditionals
- Null conditional assignment
- Parallel For-Each-Object
Other Investments
My team will also be involved in some other related investments during the time frame of working on PowerShell 7.
PowerShell in Azure Functions to generally available
A few weeks ago, Joey Aiello announced the Public Preview of PowerShell in Azure Functions 2.0. As we get feedback, my team will continue to work with the Azure Functions team to address that feedback and eventually move from public preview to being generally available.
PSReadLine 2.0
Jason Shirk has done a great job with PSReadLine. As part of Windows PowerShell 5, we decided to have it as the default interactive shell experience. As a side project to Jason, he’s made many improvements, but the project is bigger than one person. We’ve agreed to move the PSReadLine project to the PowerShell team where we can have some dedicated resources to get the 2.0.0 release to GA.
PowerShell Editor Services / Visual Studio Code PowerShell extension
We will continue to make progress on PowerShell Editor Services 2.0 release improving reliability, performance, and PSReadLine integration.
PSScriptAnalyzer
As part of improving performance for PSEditorServices, we need to make PSScriptAnalyzer 2.0 host-able so that PS Editor Services can simply call an API rather than calling PSScriptAnalyzer using a PowerShell runspace.
Summary
As you can see, we have a ton of work ahead of us. Not everything will make it in the same time frame of PowerShell 7 and some of the popular requested features may have to wait for PowerShell 7.1, but the more feedback you give us, the more we can be sure we’re doing the right thing to help you succeed.
Thanks!
Steve Lee Principal Software Engineering Manager PowerShell Team https://twitter.com/Steve_MSFT
Light
Dark
11 comments
I hope you are working with the Active Directory team to bring the AD module to PS7.
James Lunardi, you already can use AD module with PowerShell Core and PS7 but only on Windows. It doesn’t work on Unixes because .Net Core haven’t ported APIs to work with LDAP.
I woud say that it’s rather bittersweet support of AD module in PowerShell Core. Yes, you can use it but you have to import it implicitly using WindowsCompatibility module (i.e. Import-WinModule ActiveDirectory) but you can’t import it automatically from module manifest (RequiredModules section). And that alone breaks more than half of our enterprise modules.
This is the long feature that would greatly expand powershells reach. All of the other features are for users already in the eco-system and are fine using Posh 5.1. I’m truly at a loss for the lack of focus on the one thing that would be the biggest feather in the cap of this language to move to .netCore. Focusing on your windows base as it shrinks is probably not the wisest choice.
Without this Module being migrated for use on Mac and Linux then PowerShell 7 really does not have true parity. This is the module absolutely most used module across our scripts. This really needs to be a focus for PowerShell 7 adoption over Windows PowerShell 5.
I currently have these installed:
– Windows PowerShell 5.1- PowerShell Core 6.2.1
If I install the PowerShell 7 Preview, what will happen to my current installations?
In short; nothing. You can install .net core side-by-side and also PowerShell Core.
With your posh v7 ISE, what is the possibility of leaving the ISE in the same state as posh v5?
But then create your posh ISEv7 features with an extension name, may I suggest powershell_ISE_Core.exe or something?
Out-GridView:
Would the team consider parameterizing features of the skin on the WPF gridview?
Is there a timeline on when Out-Gridview will be added?
Hi,
Is there a plan to restore of ISE in PS7 or should I move to Visual Studio Code now?