PowerShell 7 Preview 3
PowerShell 7 Preview 3
In May, we published our PowerShell 7 Roadmap. We have been making progress on our roadmap and are currently on track to have a Generally Available (GA) release by end of this calendar year.
Long Term Servicing
PowerShell 7 GA will also be our first Long Term Servicing (LTS) release which is a change from our current Modern Lifecycle support for PowerShell Core 6. We will support PowerShell 7 GA for as long as .NET Core 3.1 is supported before you must upgrade to a newer version to continue to be supported by Microsoft.
Windows PowerShell compatibility
One of the main goals of PowerShell 7 is to have a viable replacement for Windows PowerShell 5.1 in production and we’ve made significant progress towards that goal.
PowerShell 7 Preview 3 is built on .NET Core 3.0 Preview 8 and leverages the work from the .NET Team to close the gap between .NET Core and .NET Framework. .NET Core 3.0 reintroduces a large number of .NET Framework APIs, opening up a large number of PowerShell modules shipped with Windows to be validated and marked as compatible by our team. Because the compatibility changes to the modules come as part of Windows, the latest version of Windows 10/Windows Server is required for full module compatibility.
However, on older versions of Windows, some modules may just work if you use:
Import-Module <moduleName> -SkipEditionCheck
If you have issues with a Microsoft PowerShell module, please open an issue in the PowerShellModuleCoverage repository!
Expect more content on this specific topic from Joey Aiello in the near future with more detail on which modules are compatible and where they’re marked as such.
New Features in Preview 3
This is just a small part of the entire changelog. New features in this preview from the community and also the PowerShell team:
Experimental Features on by default in Preview builds
We decided to enable all Experimental Features by default in order to solicit more feedback for the PowerShell Committee to determine if a feature should continue as experimental, move from experimental to stable (non-experimental), or be withdrawn. On Stable builds (as well as Release Candidates), experimental features will continue to be disabled by default.
Note that if you had previously manually enabled experimental features, your
powershell.config.jsonsettings file will take precedence and only experimental features listed within that file will be enabled. You can delete that file or run
Get-ExperimentalFeature | Enable-ExperimentalFeature to ensure all experimental features are enabled. However, if you use the pipeline, you’ll have to do it again with a future Preview release that has new experimental features.
Single Apartment Thread as default
In general, you don’t need to worry about a concept called ApartmentState which only applies to Windows.
Prior to this release
pwsh would run as a multi-threaded apartment by default. However, graphical user interface (GUI) APIs such as WinForms and WPF require a single-threaded apartment. What is important here is that
pwsh is now the same as
powershell.exe in regards to apartment state and as such support calling WinForms and WPF APIs from PowerShell script.
Display COM Method Signature Argument Names
On Windows, if you happen to call COM APIs from PowerShell, a new capability by nbkalex will now show the argument names of COM methods instead of just the type information which can be used as simple documentation indicating what arguments should be passed.
Consider DBNull and NullString as $null
If you work with database types, you may get back a
[dbnull]::Value which is equivalent to
$null within the database, but in PowerShell, this was not equal to
$null so you can’t compare it directly. This change from Joel Sallow allows you to compare both
$null and get
Read-Host -Prompt works for all input
Due to how
Read-Host calls into the console host and how the console host prompts for input (such as mandatory parameters that are given a value), you might encounter a situation where using
Read-Host to prompt for input in your script exhibits unintended behavior when certain characters are used. This has been fixed so
Read-Host will accept input as expected.
Support negative numbers with -Split operator
The -Split operator splits one or more strings into substrings. You can optionally specify a value to indicate the maximum number of substrings you want returned.
This new capability by Jacob Scott now allows you to specify the maximum number of substrings as a negative value signifying that the split should happen right to left instead of the usual left to right.
We’ve received consistent feedback that PowerShell users use PSWorkflow primarily to easily run scriptblocks in parallel.
We’ve added a
-Parallel parameter to
ForEach-Object that accepts a scriptblock to execute in parallel. There is an optional
-ThrottleLimit parameter to set the maximum threads to use in parallel where it defaults to 5.
Resolve AppX reparse points
On Windows 10, if you have apps installed from the Windows Store and list them in the command line, they show up as 0 byte files. These files are actually a different type of link to the actual executable. With this change, the target executable will now show up when using
pwsh as a login shell
On Linux and macOS systems, there is a concept of a login shell which sets up the environment from which other apps and shells inherit. Prior to this release if you used
pwsh as your default login shell, you may have noticed that some environment variables are missing or incomplete.
With this change,
pwsh will work the same as
sh Bourne Shell in how it sets up the login environment so that everything works correctly.
In this Preview release, we’ve added more telemetry. Please see Sydney Smith‘s blog post on New Telemetry in PowerShell 7 Preview 3.
Although this blog post focuses on new features, this release also contains many bug fixes as well as targeted performance improvements.
You can always get the latest version of PowerShell from https://aka.ms/get-powershell.
Expect more new features from the community and the PowerShell team in future Preview releases!
Steve Lee PowerShell Team
My primary problem is with powershell core when connected to a remote system, I couldn’t find a functional text editor that works in powershell console. How do you edit the files on a remote system (besides downloading and reuploading them) ?
+1, I had not the best experience trying use nano in pwsh on Windows
Upd today gonna check it on linux
Well, you can install git bash and grep for windows and be happy with that, both nano and vim seem to work fine on your localhost.
But I had issues with nano and vim running them via ssh.
Actually, in my case target OS is windows. I don’t think anyone would ever use PowerShell for anything serious as the above scenario is not supported. Come to think of it, there is no way to edit remote files!
Can you clarify PS 6/7 Windows native ARM64 support. I use PS 6.2 on Windows native ARM64 and it seems to work fine . Currently the .Net Core 2.x and 3.x releases claim no Windows ARM64 support, yet pwsh, which is .Net based is released on Windows ARM64 (and has been for a while)? I can run PS 6.2 on ARM64 WinPE, which has no x86 emulator support, so it must be running native ARM64. Are you using a private .Net build in PS 6/7 to make this work?
if someone could add a global parameter to powershell or at the very least BitsTransfer to ignore invalid or self signed cert that would make my day.
Speaking of Com objects, it would be nice if someone finally fixed the msi com object, windowsinstaller.installer (type library? IDispatch?).