News

PowerShell Plans Unveiled After .NET 7 Hiccup

• By David Ramel
• 03/07/2022

The PowerShell dev team unveiled its 2022 plans, including a move to the upcoming .NET 7, a project that has been delayed by some issues.

"We will continue to align with new .NET releases which means moving to .NET 7," said Steve Lee, principal software engineer manager, in a March 4 blog post. "We continue to work closely with the .NET team to align our releases, however we found some issues in .NET 7 preview 1 so we couldn't ship PowerShell 7.3 preview 2 with .NET 7. As early adopters of .NET 7, we expect to hit issues on occasion with the intent to get them resolved before we consider a release candidate."

PowerShell 7.2 shipped last November with .NET 6 as a long-term support (LTS) release (supported for three years), and v7.3 is expected to hit general availability toward year's end as a stable release that's supported for one year.

As the team progresses toward v7.3, Lee outlined more than a dozen areas of focused investment ranging from "local SessionConfiguration support" to "more Windows ARM64 support" to "OpenSSH for Windows."

Regarding that latter item, he said: "Our team continues to support the Windows port of OpenSSH. We continue to publish experimental beta releases on GitHub to get user feedback prior to updating the OpenSSH shipped in Windows. Expect new releases on GitHub to be MSI packages instead of zip packages making them easier to install and update. We'll continue to fix bugs as well as add new parity features to the Windows port. There's some other exciting work happening with SSH that we aren't quite ready to discuss yet."

The latest of those experimental beta releases includes several security fixes:

• For non en-us OS, enforce authorized keys for admin users are read from $env:programdata\ssh\administrators_authorized_keys (#1757)
• Ensure only admin users have access to modify the registry entries like DefaultShell (#1754)
• Use $env:programdata\ssh\ssh_config only if it has correct file permissions (non-admin users shouldn't have write permissions) (#1753)

Here are some other highlights from the planning post:

• PowerShell Gallery: The team is exploring future architectural changes for the seven-year-old gallery, whose usage growth has surpassed expectations.

  

• PowerShell 7 in Windows: The team is exploring a cmdlet-based installation approach for PowerShell 7 on Windows after considering and then rejecting a complicated bootstrapper approach to the thorny installation problem. It's difficult because PowerShell 7 can't be shipped within Windows itself because of size constraints and support lifecycle differences between Windows and .NET. More details are expected soon in a Request for Comments (RFC).
• Making it easier to find out what's new in PowerShell: the team is eyeing a Get-WhatsNew cmdlet to help users find out what's new in PowerShell to supplement the team's outreach via Twitter and blog posts. More details coming soon in an RFC.
• More Windows ARM64 support: In response to a customer/partner request, the team will replace the zip package installation scheme with a Windows ARM64 MSI installation package to serve the growing number of users, which will require additional work to make it compatible with Microsoft Update.
• Module isolation: The team is wrestling with the complicated problem of dependency conflicts that are arising with increased usage because .NET only allows one version of an assembly to be loaded at a time. That means a newer assembly version needed by a module won't be loaded if an older version of the assembly was already loaded. There's a workaround, but it's "still quite complicated" so the team is working on some improvements in PowerShell 7 to make it easier, supplemented with sample code.
• PowerShell VSCode extension: Significant threading changes have improved performance and reliability of the tool, and the team plans to continue to fix bugs and focus on moving the preview release to a stable release.
• Crescendo 1.0: This is expected to hit GA soon following the release of a Crescendo 1.0 Release Candidate last December.
• PowerShellGet 3.0: Work on this complete rewrite of PowerShellGet focuses on a few key areas:
  • Simplify code base making it easier to enhance and fix bugs (which includes moving aware from dependency on PackageManagement)
  • Address long standing usability issues that would have been breaking changes from v2
  • Maintain compatibility for existing scripts written expecting v2

Other details are provided about: predictive IntelliSense; local SessionConfiguration support; additional Azure Mariner support; custom ConnectionInfo; AMSI and WDAC enhancements; macOS Notarization support; and more.

"As you can see, we have lots of work on our plate," Lee said. "Our plans are not set in stone and we'll adjust them as new compliance or customer/partner requirements come in. Finally, thanks to the amazing community! Your feedback and contributions are greatly appreciated and results in a better product for everyone."