Remove PowerShell 2.0 Compatibility References#4
Conversation
Removed all references to PowerShell 2.0 compliance throughout the codebase and updated them to require PowerShell 5.0+ as PowerShell 2.0 is now completely deprecated. Updated files: - Template files (Application and Script templates) - Component files (ScanSnapHome) - Shared function libraries (Logging, Software Detection, Validation, File Operations, Registry Helpers, Network Utils) All scripts now require PowerShell 5.0 or higher. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Updated the PSVersion requirement from 2.0 to 5.0 in the FocusedDebloat script to align with the repository-wide PowerShell 5.0+ requirement. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
aybouzaglou
deleted the
claude/remove-powershell-2-compliance-011CUSEks9mD2ti7UwYEuEXN
branch
Summary of ChangesHello @aybouzaglou, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request systematically updates the declared PowerShell compatibility for various scripts and templates from PowerShell 2.0+ to PowerShell 5.0+. The primary purpose of this change is to modernize the codebase's stated requirements, ensuring alignment with current PowerShell environments and potentially paving the way for the adoption of newer language features and cmdlets. The impact is a clearer understanding of the expected runtime for these components and a move away from legacy PowerShell versions. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request removes references to PowerShell 2.0 compatibility and updates them to PowerShell 5.0+ in several PowerShell scripts. The changes primarily involve updating the compatible PowerShell version in the script headers and documentation. The review focuses on ensuring the changes are correctly applied and that no unintended consequences arise from dropping support for older PowerShell versions.
| customwhitelist(String) ; skipwindows(Boolean) ; skiphp(Boolean) ; skipdell(Boolean) ; skiplenovo(Boolean) | ||
| .REQUIRES | ||
| LocalSystem ; PSVersion >=2.0 | ||
| LocalSystem ; PSVersion >=5.0 |
There was a problem hiding this comment.
The script's .REQUIRES directive now specifies PSVersion >= 5.0. Ensure that all functions and cmdlets used in this script are compatible with PowerShell 5.0 and later. Verify that no functionality is lost due to the removal of PowerShell 2.0 compatibility.
Consider adding a comment explaining why PowerShell 5.0 is now required, highlighting any specific features or cmdlets used that necessitate this version.
| - File attachment support for installers | ||
| - Registry-based software detection | ||
| - PowerShell 2.0+ compatible | ||
| - PowerShell 5.0+ compatible |
There was a problem hiding this comment.
The template is now marked as PowerShell 5.0+ compatible. Ensure that all embedded functions and example code within this template are indeed compatible with PowerShell 5.0 and later. Verify that no functionality is lost due to the removal of PowerShell 2.0 compatibility.
Suggestion: Add a comment highlighting any specific features or cmdlets used that necessitate PowerShell 5.0+.
| - Flexible timeout support | ||
| - System state validation | ||
| - PowerShell 2.0+ compatible | ||
| - PowerShell 5.0+ compatible |
There was a problem hiding this comment.
The template is now marked as PowerShell 5.0+ compatible. Ensure that all embedded functions and example code within this template are indeed compatible with PowerShell 5.0 and later. Verify that no functionality is lost due to the removal of PowerShell 2.0 compatibility.
Suggestion: Add a comment highlighting any specific features or cmdlets used that necessitate PowerShell 5.0+.
| # Use .NET Framework for ZIP extraction (PowerShell 5.0+ compatible) | ||
| Add-Type -AssemblyName System.IO.Compression.FileSystem | ||
| [System.IO.Compression.ZipFile]::ExtractToDirectory($ArchivePath, $DestinationPath) |
There was a problem hiding this comment.
The comment indicates that .NET Framework is used for ZIP extraction and is PowerShell 5.0+ compatible. This comment should accurately reflect the current compatibility requirement. If the code relies on features specific to PowerShell 5.0 or later for ZIP extraction, this comment is appropriate. Otherwise, consider rephrasing to avoid confusion.
Suggestion: Verify if the .NET Framework usage indeed requires PowerShell 5.0+ and adjust the comment accordingly.
| switch ($ArchiveType) { | ||
| 'ZIP' { | ||
| # Use .NET Framework for ZIP extraction (PowerShell 2.0 compatible) | ||
| # Use .NET Framework for ZIP extraction (PowerShell 5.0+ compatible) |
There was a problem hiding this comment.
The comment indicates that .NET Framework is used for ZIP extraction and is PowerShell 5.0+ compatible. However, the code itself doesn't seem to have changed. If the underlying implementation relies on PowerShell 5.0+ features, this change is correct. Otherwise, it might be misleading.
Suggestion: Double-check if the .NET Framework usage truly necessitates PowerShell 5.0+ and update the comment accordingly. If not, revert the comment to reflect the actual compatibility.
2 participants
No description provided.