PowerShell Team May 2020 Update
Previously, I published a blog on our investments plans during the PowerShell 7.1 release timeframe. We’ve made progress across many of those investments with more work ahead of us.
PowerShell 7.1 preview 3
We are now able to ship simultaneously with each new .NET 5 preview release!
This means that you can start leveraging new capabilities in .NET 5 and assess the new performance improvements. For PowerShell it means we can find issues early during integration with .NET and get those issues resolved much more quickly. Because we will be able to simultaneously release with .NET, it also means users will get have the full support lifecycle of .NET with PowerShell.
The engineering work required to enable this means we missed one .NET 5 preview release, so unfortunately, our preview numbers don’t align. Today’s PowerShell 7.1 preview 3 release is built on top of .NET 5 preview 4! This includes preview builds of PowerShell for Windows on ARM64!
Grab the latest version from the usual places or from our GitHub repo where you can also read the detailed change log.
New experimental feature
In PowerShell 7.0, we added a
temp: PSDrive. This works on all platforms and automatically maps to your user temporary path. However, native commands do not understand PowerShell drives, so if you wanted to quickly edit a temporary file using
vim, you can’t just specify
temp:/test.ps1 expecting that to just work.
This new experimental feature called
PSNativePSPathResolution will automatically resolve file system PSPaths and pass that path to the native command. Note that if you use single quotes, then that string is passed as a literal string to the native command instead of being resolved. If the path is not a valid file system path (for example, a registry provider path like
HKLM:\myRegKey), then it will just be passed as a literal string to the native command.
Also, new for Windows, you can use
~ to be reference your home directory for native commands as the path will also be resolved before passing it to the native command. So you can also do something like
As a reminder, preview releases of PowerShell, by default, have experimental features enabled to solicit feedback.
If you have any issues or suggestions for this feature, please open or comment on an existing issue in our repo.
Much of the work the team is focused on is not (currently) shipped with PowerShell.
We shipped the 3rd preview of this module and development continues. Currently,
Save is working. In the next preview we expect
Publish to be working.
The goal of PowerShellGet 3.0 is to simplify the user experience so you don’t get error messages telling you to add more switches to do what you intended. Also, we removed the dependency on PackageManagement module and nuget.exe so updating PowerShellGet should be much easier. Finally, we want to address the developer scenario making it easier to specify and install bulk dependencies.
Expect a new preview every few weeks to a month as new features light up!
Please report issues or suggestions to the PowerShellGet repo.
Based on user feedback as well as our own discussions, we decided to invest in a major re-architecture of how we store secrets locally. The current preview only supports Windows because of the dependency on Windows Credential Manager. Unfortunately, Windows Credential Manager does not support two important use cases because it requires an interactive token:
- Service accounts cannot access Windows Credential Manager
- You can’t use Secret Management module over PowerShell remoting (or any network token)
We also found by experimenting with support of libsecret that the Linux experience would be different from Windows in that Linux will prompt for a passcode while Windows does not.
We’ll be sharing more details of our new local vault design which will provide a consistent experience across Windows, Linux, and macOS while remaining secure.
Expect this new local vault to be available in the next preview release.
Please report issues or suggestions to the PowerShell modules repo.
v1.19.0 of PSScriptAnalzyer shipped recently. This release has significant improvements to formatting as well as a number of new script analysis rules! Most of this work was done by the community. Thank you!
We are actively discussing and designing our next major version focusing on performance improvements that should make using PSSA in VSCode much snappier.
Please report issues or suggestions to the PSScriptAnalyzer repo.
Jupyter Notebook support
- Enable connecting to Azure CloudShell
- Host prompting works, so you can use
- Plotting cmdlets and type accelerators
- Proper colors and formatting from console to notebook
- Lots of examples included
A reminder that to get PowerShell language support, you just need to install dotnet-interactive!
Please report issues or suggestions to the dotnet-interactive repo.
There’s still lots of work ahead of us as we target the 7.1 release towards the end of this calendar year. We expect to continue to have a new preview release every month for PowerShell and for our modules as new capabilities get completed. We really appreciate the early feedback from the community and partners using our previews as it helps improve the product before we finalize design decisions.
Steve Lee Principal Engineering Manager PowerShell Team