Windows 10: PowerShell 7.1.0 preview 7 released

Brink · Sep 9, 2020

Breaking Changes

Fix $? to not be $false when native command writes to stderr (#13395)

Engine Updates and Fixes

Initial work of the subsystem plugin model (for minimal powershell) (#13186)

Optimize GetSystemLockdownPolicy for non-lockdown scenarios (#13438)

General Cmdlet Updates and Fixes

Revert "Add the parameter -Paged to Get-Help to support paging (#13374)" (#13519)

Add support for TLS 1.3 in Web cmdlets (#13409) (Thanks @iSazonov!)

Add null check for args in CommandLineParser (#13451) (Thanks @iSazonov!)

Process reparse points for Microsoft Store applications (#13481) (Thanks @iSazonov!)

Move PSNullConditionalOperators feature out of experimental (#13529)

Move PSNativePSPathResolution feature out of Experimental (#13522)

Use field if property does not exist for ObRoot when using PowerShell Direct to container (#13375) (Thanks @hemisphera!)

Suppress UTF-7 obsolete warnings (#13484)

Avoid multiple enumerations of an IEnumerable<Expression> instance in Compiler.cs (#13491)

Change Add-Type -OutputType to not support ConsoleApplication and WindowsApplication (#13440)

Create warnings when UTF-7 is specified as an encoding (#13430)

Code Cleanup

We thank the following contributors!

@xtqqczze, @tamasvajk

Tools

vscode: Add editorconfig to recommended extensions (#13537) (Thanks @xtqqczze!)

Remove the out-dated ZapDisable related code from build.psm1 (#13350) (Thanks @jackerr3!)

Tests

Disable WMF download link validation test (#13479)

Click to expand...

Read more: PowerShell 7.1.0 preview 6 released

:)

Brink · Sep 9, 2020

PowerShell 7 Preview 6 now available

Today we shipped PowerShell 7 Preview.6! This release contains a number of new features and many bug fixes from both the community as well as the PowerShell team. See the Release Notes for all the details of what is included in this release.

This will be the last preview release as we head towards a Release Candidate in December. For the Release Candidate, there will be no more new features although small changes to cmdlets may still be accepted depending on risk of the change. Bug fixes will still be accepted but also accessed for their risk of causing a regression. Finally, we expect General Availability of PowerShell 7 in January as our first Long Term Servicing release.

New Features in Preview 6

This release has a number of new features from both the community as well as the PowerShell team. Remember that preview releases of PowerShell are installed side-by-side with stable versions so you can use both and provide us feedback on previews for bugs and also on experimental features.

You can read about new features in previous preview releases:

PowerShell 7 Preview 5

PowerShell 7 Preview 4

PowerShell 7 Preview 3

There were new features in Preview 1 and Preview 2, but I didn’t blog about them… sorry!

Skip Error Check for Web Cmdlets

Great addition by community member Vincent Damewood to allow skipping the internal HTTP response error check within the web cmdlets. This means that you can now handle the web error yourself including getting the response object as well as the HTTP response headers whereas previously you would have to get it from the resulting error object.

Null Conditional Member Property and Method Access

This is a new language feature that allows you to skip checking if a variable is $null before indexing into the variable, calling a method, or accessing a property. For properties, PowerShell will already allow accesing properties of $null, but this new syntax makes it more clear the intent in the script. Note that because PowerShell allows variable names to end with a question mark, you must use braces around the variable name

Extended Unix Filesystem Information

For users of PowerShell on Linux and macOS, they may miss some of the additional information of the filesystem provided by ls -l (long form of a directory listing). This new feature makes that information available using Get-ChildItem so you are no longer missing any useful information.

Windows PowerShell Compatibility in Preview 6

This release also improves the compatibility of PowerShell 7 with Windows PowerShell 5.1. We’ve brought back many existing cmdlets from Windows PowerShell 5.1 thanks to .NET Core 3! In addition, we have a new feature included with PowerShell 7 that encapsulates the Windows Compatibility Module (more on that below!).

Clipboard Cmdlets

Get-Clipboard and Set-Clipboard are back! Not only are they available again, but they are cross platform compatible which means you can use them on Linux (requires xclip to be installed) and macOS. Note that only text is supported at this time even on Windows.

Performance Counter Cmdlets

Get-Counter is back allowing you to get Windows performance counter information. Note that Import-Counter and Export-Counter cmdlets are not supported in PowerShell 7.

Graphical Tools Cmdlets

With .NET Core 3.0 bringing back WPF support on Windows, we’ve been able to bring back some popular graphical tools. Out-GridView gives a dynamic table view of results in a pipeline with sorting and filtering capabilities and when used with -PassThru can be used interactively within a pipeline to select objects to send back to the pipeline. Show-Command gives a graphical view of a command including parameter sets, parameters, switches, etc… Finally, Get-Help -ShowWindow works again to give a graphical view of PowerShell help content.

Update-List, Out-Printer, and Clear-RecycleBin cmdlets

Update-List allows adding/removing items from a property value that contains a collection of objects within a pipeline. This cmdlet is cross-platform compatible.

Out-Printer sends a PowerShell object to the printer. This cmdlet is only supported on Windows currently.

Clear-RecycleBin empties the recycle bin and is currently only supported on Windows.

Test-Connection Improvements

The original implementation of Test-Connection in Windows PowerShell relied on WMI which made it not cross-platform compatible.

Community member and PowerShell repo maintainer Ilya Sazonov ported the cmdlet to work against .NET Core APIs in PowerShell Core 6 making it work cross-platform. However, this also changed the user experience.

For PowerShell 7, Joel Sallow, another community member made improvements to this cmdlet and also getting back to similar experience as the original cmdlet in Windows PowerShell.

Import Windows PowerShell Modules in PS7

For PowerShell Core 6, we introduced the Windows Compatibility Module to allow importing Windows PowerShell modules that were not compatible with PowerShell Core 6 leveraging WinRM and implicit remoting.

In PowerShell 7, we have included this functionality into Import-Module directly without relying on WinRM, but does rely on Windows PowerShell 5.1 (it won’t work if Windows PowerShell 5.1 is not available).

Basically, for modules in the System32 folder, if the module manifest doesn’t indicate that module is compatible with Core then that module will be loaded in a Windows PowerShell process and using implicit remoting reflected into your PowerShell 7 session.

More details of this feature along with other information regarding Windows PowerShell compatibility in general coming in a separate blog post.

Closing

These are the last of the big changes coming in PowerShell 7 as we heads toward a Release Candidate next month. Please try out this preview and report issues in our GitHub repo as we still have opportunity to fix existing bugs as well as new bugs introduced by these features.

Thanks!
Steve Lee
PowerShell Team
Click to expand...

Source: https://devblogs.microsoft.com/power...l-7-preview-6/

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

Brink · Sep 9, 2020

The Next Release of PowerShell - PowerShell 7

Recently, the PowerShell Team shipped the Generally Available (GA) release of PowerShell Core 6.2. Since that release, we’ve already begun work on the next iteration!

We’re calling the next release PowerShell 7, the reasons for which will be explained in this blog post.

Why 7 and not 6.3?

PowerShell Core usage has grown significantly in the last two years. In particular, the bulk of our growth has come from Linux usage, an encouraging statistic given our investment in making PowerShell viable cross-platform. This chart represents the number of times pwsh.exe (or just pwsh on Linux/macOS) was started (unless telemetry was disabled).

However, we also can clearly see that our Windows usage has not been growing as significantly, surprising given that PowerShell was popularized on the Windows platform. We believe that this could be occurring because existing Windows PowerShell users have existing automation that is incompatible with PowerShell Core because of unsupported modules, assemblies, and APIs. These folks are unable to take advantage of PowerShell Core’s new features, increased performance, and bug fixes. To address this, we are renewing our efforts towards a full replacement of Windows PowerShell 5.1 with our next release.

This means that Windows PowerShell and PowerShell Core users will be able to use the same version of PowerShell to automate across Windows, Linux, and macOS and on Windows, and PowerShell 7 users will have a very high level of compatibility with Windows PowerShell modules they rely on today.

We’re also going to take the opportunity to simplify our references to PowerShell in documentation and product pages, dropping the “Core” in “PowerShell 7”. The PSEdition will still reflect Core, but this will only be a technical distinction in APIs and documentation where appropriate.

Note that the major version does not imply that we will be making significant breaking changes. While we took the opportunity to make some breaking changes in 6.0, many of those were compromises to ensure our compatibility on non-Windows platforms. Prior to that, Windows PowerShell historically updated its major version based on new versions of Windows rather than Semantic Versioning

.NET Core 3.0

PowerShell Core 6.1 brought compatibility with many built-in Windows PowerShell modules, and our estimation is that PowerShell 7 can attain compatibility with 90+% of the inbox Windows PowerShell modules by leveraging changes in .NET Core 3.0 that bring back many APIs required by modules built on .NET Framework so that they work with .NET Core runtime. For example, we expect Out-GridViewto come back (for Windows only, though)!

A significant effort for PowerShell 7 is porting the PowerShell Core 6 code base to .NET Core 3.0 and also working with Windows partner teams to validate their modules against PowerShell 7.

Support Lifecycle Changes

Currently, PowerShell Core is under the Microsoft Modern Lifecycle Policy. This means that PowerShell Core 6 is fix-forward: we produce servicing releases for security fixes and critical bug fixes, and you must install the latest stable version within 6 months of a new minor version release.

In PowerShell 7, we will align more closely with the .NET Core support lifecycle, enabling PowerShell 7 to have both LTS (Long Term Servicing) and non-LTS releases.

We will still have monthly Preview releases to get feedback early.

When do I get PowerShell 7?

The first Preview release of PowerShell 7 will likely be in May. Be aware, however, that this depends on completing integration and validation of PowerShell with .NET Core 3.0.

Since PowerShell 7 is aligned with the .NET Core timeline, we expect the generally available (GA) release to be some time after the GA of .NET Core 3.0.

What about shipping in Windows?

We are planning on eventually shipping PowerShell 7 in Windows as a side-by-side feature with Windows PowerShell 5.1, but we still need to work out some of the details on how you will manage this inbox version of PowerShell 7.

And since the .NET Core timeline doesn’t align with the Windows timeline, we can’t say right now when it will show up in a future version of Windows 10 or Windows Server.

What other features will be in PowerShell 7?

We haven’t closed on our feature planning yet, but expect another blog post relatively soon with a roadmap of our current feature level plans for PowerShell 7.

Steve Lee
https://twitter.com/Steve_MSFT
Principal Engineering Manager
PowerShell Team
Click to expand...

Source: The Next Release of PowerShell - PowerShell 7 | PowerShell

Brink · Sep 9, 2020

The Next Release of PowerShell - PowerShell 7

Recently, the PowerShell Team shipped the Generally Available (GA) release of PowerShell Core 6.2. Since that release, we’ve already begun work on the next iteration!

We’re calling the next release PowerShell 7, the reasons for which will be explained in this blog post.

Why 7 and not 6.3?

PowerShell Core usage has grown significantly in the last two years. In particular, the bulk of our growth has come from Linux usage, an encouraging statistic given our investment in making PowerShell viable cross-platform. This chart represents the number of times pwsh.exe (or just pwsh on Linux/macOS) was started (unless telemetry was disabled).

However, we also can clearly see that our Windows usage has not been growing as significantly, surprising given that PowerShell was popularized on the Windows platform. We believe that this could be occurring because existing Windows PowerShell users have existing automation that is incompatible with PowerShell Core because of unsupported modules, assemblies, and APIs. These folks are unable to take advantage of PowerShell Core’s new features, increased performance, and bug fixes. To address this, we are renewing our efforts towards a full replacement of Windows PowerShell 5.1 with our next release.

This means that Windows PowerShell and PowerShell Core users will be able to use the same version of PowerShell to automate across Windows, Linux, and macOS and on Windows, and PowerShell 7 users will have a very high level of compatibility with Windows PowerShell modules they rely on today.

We’re also going to take the opportunity to simplify our references to PowerShell in documentation and product pages, dropping the “Core” in “PowerShell 7”. The PSEdition will still reflect Core, but this will only be a technical distinction in APIs and documentation where appropriate.

Note that the major version does not imply that we will be making significant breaking changes. While we took the opportunity to make some breaking changes in 6.0, many of those were compromises to ensure our compatibility on non-Windows platforms. Prior to that, Windows PowerShell historically updated its major version based on new versions of Windows rather than Semantic Versioning

.NET Core 3.0

PowerShell Core 6.1 brought compatibility with many built-in Windows PowerShell modules, and our estimation is that PowerShell 7 can attain compatibility with 90+% of the inbox Windows PowerShell modules by leveraging changes in .NET Core 3.0 that bring back many APIs required by modules built on .NET Framework so that they work with .NET Core runtime. For example, we expect Out-GridViewto come back (for Windows only, though)!

A significant effort for PowerShell 7 is porting the PowerShell Core 6 code base to .NET Core 3.0 and also working with Windows partner teams to validate their modules against PowerShell 7.

Support Lifecycle Changes

Currently, PowerShell Core is under the Microsoft Modern Lifecycle Policy. This means that PowerShell Core 6 is fix-forward: we produce servicing releases for security fixes and critical bug fixes, and you must install the latest stable version within 6 months of a new minor version release.

In PowerShell 7, we will align more closely with the .NET Core support lifecycle, enabling PowerShell 7 to have both LTS (Long Term Servicing) and non-LTS releases.

We will still have monthly Preview releases to get feedback early.

When do I get PowerShell 7?

The first Preview release of PowerShell 7 will likely be in May. Be aware, however, that this depends on completing integration and validation of PowerShell with .NET Core 3.0.

Since PowerShell 7 is aligned with the .NET Core timeline, we expect the generally available (GA) release to be some time after the GA of .NET Core 3.0.

What about shipping in Windows?

We are planning on eventually shipping PowerShell 7 in Windows as a side-by-side feature with Windows PowerShell 5.1, but we still need to work out some of the details on how you will manage this inbox version of PowerShell 7.

And since the .NET Core timeline doesn’t align with the Windows timeline, we can’t say right now when it will show up in a future version of Windows 10 or Windows Server.

What other features will be in PowerShell 7?

We haven’t closed on our feature planning yet, but expect another blog post relatively soon with a roadmap of our current feature level plans for PowerShell 7.

Steve Lee
https://twitter.com/Steve_MSFT
Principal Engineering Manager
PowerShell Team
Click to expand...

Source: The Next Release of PowerShell - PowerShell 7 | PowerShell

Windows 10: PowerShell 7.1.0 preview 7 released

PowerShell 7.1.0 preview 7 released

PowerShell 7.1.0 preview 7 released

PowerShell 7.1.0 preview 7 released

PowerShell 7.1.0 preview 7 released - Similar Threads - PowerShell preview released

Removing powershell 7

Powershell 7 !

Powershell 7 !

Powershell 7 !

PowerShell 7.2.0 preview 1 released

PowerShell 7 Preview 6 now available

PowerShell 7 Preview 5 now available

PowerShell 7 Road Map published along with Preview1 release

The Next Release of PowerShell - PowerShell 7