Steve Lee: State of the Shell: PowerShell7

Team Overview and Scope

• The speaker is the Engineering Manager for the PowerShell team, leading 11 engineers and collaborating with four program managers and General Manager Jason Helmick.
• The team manages all PowerShell-related assets on GitHub, the PowerShell Gallery, VS Code extensions, Group Analyzer, OpenSSL, PSReadLine, and PowerShell Get.
• Strategic Shift: Windows PowerShell 5.1 servicing was handed off to the Windows OS team; the PowerShell team no longer owns its servicing or new feature development.

Windows PowerShell 5.1 Status

• Windows PowerShell 5.1 is considered complete; there are no plans for version 5.2, 6, or 7 within the Windows OS.
• No plans exist to remove Windows PowerShell 5.1 from the OS due to deep dependency on legacy applications.
• The version will receive critical security fixes and bug fixes but no new features.
• Recommendation: Users with existing business workloads should maintain 5.1, while those needing new features should run PowerShell 7 side-by-side.

PowerShell 7 Roadmap and Versioning

• Naming Change: The "Core" designation was dropped to signal that the product is the full, primary version of PowerShell, not a subset.
• Version Alignment: PowerShell 7 is conceptually PowerShell Core 6.3; versioning will align with the .NET yearly release cycle (e.g., 7.1 based on .NET 5, 7.2 on .NET 6).
• LTS Support: PowerShell 7 is a Long-Term Servicing (LTS) release aligned with .NET Core 3.1, guaranteeing security and critical bug fixes for three years.
• Deprecation Timeline: PowerShell Core 6.2 support ends in July (six months after PowerShell 7 GA in January), aligning with the end of its modern lifecycle.
• Future Versions: There is currently no plan to release PowerShell 8.
• Windows Inbox Status: PowerShell 7 will not be shipped in the Windows OS inbox due to support lifecycle mismatches (Windows supports 5+5 years vs. .NET's 3-year LTS).

Key Features and Improvements

• Error Handling: Default error output is now concise; users can switch to the "Classic" view or use Get-Error for stack traces and full details.
• HTTP Error Suppression: Invoke-WebRequest and Invoke-RestMethod now support the -SkipHttpErrorCheck parameter, allowing users to handle HTTP failure status codes (e.g., 401, 415) as objects rather than fatal PowerShell errors.
• Null Propagation: New language syntax allows conditional member access (e.g., $obj?.Prop) without explicit null checks; braces are required for this syntax to avoid ambiguity.
• Array Null Propagation: The ?. operator now works on array elements (e.g., $obj?.[1]), returning null if the index is out of bounds.
• Null Coalescing and Assignment: New ?? (coalesce) and ??= (coalesce assignment) operators simplify logic for default values (e.g., $admin ??= $user).
• Ternary Operator: An inline if-else syntax is available for conditional expressions.
• Parallel Processing: ForEach-Object -Parallel enables concurrent execution of pipeline steps, utilizing system cores to improve performance for I/O-bound tasks.
• Unix File Info: Get-ChildItem on Unix systems now displays extended attributes (owner, group, permissions) similar to the ls -l command.
• Variable Completion: Tab completion now supports enum values and typed variables for better autocomplete.
• Debugging: The ErrorActionPreference = 'Break' setting allows scripts to enter the debugger immediately upon encountering an error.
• Selection Emphasis: Select-String now highlights matched text directly in the output using terminal color codes.

Windows Module Compatibility

• Implicit Remoting: PowerShell 7 can now import modules marked as "Windows-only" by launching a hidden Windows PowerShell process to invoke the commands via the Job infrastructure (no WinRM required).
• Supported Modules: Modules like Active Directory and Server Manager now work via implicit remoting, though output may be deserialized.
• Unsupported Modules: Modules relying on WinForms or private APIs (e.g., LocalAccount, ControlPanel, Get-Printer) remain unavailable unless they are rewritten for .NET Core.
• WinForms/WPF: WPF and WinForms are now supported in PowerShell 7 on Windows, enabling the restoration of Get-Clipboard and other legacy cmdlets.
• Remoting Protocol: SSH remoting is the recommended cross-platform protocol; WinRM over SSH is supported, but WinRM over Kerberos is not available on Linux/macOS.

PowerShell Get and Gallery (v2 to v3 Transition)

• v2 Limitations: Current PowerShellGet v2 relies on the deprecated PackageManagement infrastructure and has poor user experience regarding version resolution.
• v3 Strategy: The team plans to rewrite PowerShellGet v3 in C#, removing dependency on PackageManagement to improve performance and maintainability.
• NuGet Syntax: v3 will adopt standard NuGet versioning syntax (e.g., >=3.0 <4.0) for better dependency management.
• Release Timeline: PowerShellGet v3 will not be included in the PowerShell 7 GA; a preview is expected in Q1 of the following year.
• Local Caching: v3 will introduce a local cache to speed up module installation and provide better feedback on missing commands.

Performance and Startup

• Runtime Performance: Scripts run faster in PowerShell 7 due to .NET Core optimizations compared to .NET Framework.
• Startup Time: PowerShell 7 starts slower (approx. 600-800ms) than Windows PowerShell 5.1 (approx. 300-400ms) due to the lack of a Global Assembly Cache (GAC) and JIT compilation differences.
• Future Optimization: Startup times are a known focus area for PowerShell 7.1 but achieving parity with 5.1 is unlikely without a fundamental engine change.

Q&A and Community Engagement

• Committee Structure: The PowerShell Language Committee is currently a closed group; plans are being discussed to expand membership and separate strategic from technical oversight.
• RFC Review: The team acknowledges a backlog in reviewing community RFCs and is exploring lighter-weight discussion processes to speed up feedback.
• Azure Functions: The PowerShell team built the language worker for Azure Functions 2.0; ownership was transferred to the Azure Functions team, which is expected to support PowerShell 7 soon.
• Intune Module: The PowerShell team does not own the Intune module; users are encouraged to contact the Intune team directly for feature requests.