PSScriptAnalyzer (PSSA) 1.21.0 has been released

Jim Truher

Overview

We are happy to announce the release of PSScriptAnalyzer 1.21. This minor version update includes:

• Three new rules
• Enhances one rule
• Pipeline support to Invoke-Formatter
• Four bug fixes
• Improved message details in PSUseCorrectCasing
• Lots of documentation updates
• Updated system requirements

A big portion of changes are in less visible areas such as the maintenance of dependencies and CI.

System requirements

Starting with this version the minimum requirements are changing as follows:

• For PowerShell ‘Core’ users ($PSVersionTable.PSEdition -eq 'Core'):

  The minimum required PowerShell version increases from 7.0.3 to 7.0.11. With PowerShell 7.0 reached end of life this December, the next version of PSScriptAnalyzer will require 7.2.

  Use $PSVersionTable.PSVersion to see which version of PowerShell you are using. For more information about supported versions of PowerShell, see the PowerShell support lifecycle.

• For Windows PowerShell users (version 3 to 5.1 or ($PSVersionTable.PSEdition -ne 'Core'))

  The minimum required version of the .NET Framework runtime increased from 4.5.2 to 4.6.2. Versions 4.5.2., 4.6 and 4.6.1 have reached end of support this year. This change should not impact the majority of users on supported and patched OS versions.

  For more details about .NET support, see .NET Framework blog post.

For more information, see the full changelog.

New Rules

AvoidMultipleTypeAttributes

This rule is to call out the usage of multiple type attributes in a function that the parser accepts as valid syntax but can later cause unexpected behavior or an error at runtime.

For example, the following function

function foo { [switch][string] $Param1 }

will throw the following error when the function is invoked:

Cannot convert the “” value of type “System.String” to type “System.Management.Automation.SwitchParameter”

Thanks to GitHub user hankyi95 for contributing this rule.

AvoidSemicolonsAsLineTerminators

The rule detects the usage of a trailing semicolon at the end of a line, which is not required in most PowerShell scripts and can be omitted. This rule is not enabled by default and can be used by Invoke-Formatter.

The latest Preview version of the PowerShell extension for Visual Studio Code already includes PSScriptAnalyzer 1.21.0 and can control this formatting rule via a new powershell.codeFormatting.avoidSemicolonsAsLineTerminators setting. This should soon be available in the non-preview version of the extension as well.

Thanks to Aliaksei (GitHub user tempora-mutantur) for contributing this rule.

AvoidUsingBrokenHashAlgorithms

This rule inspects the Get-FileHash cmdlet for usage of either MD5 or SHA-1 as the value to the -Algorithm parameter since those algorithms are no longer considered secure. Users should consider replacing the value with SHA256, SHA384, SHA512, or other safer algorithms where possible. It is understood there will be legacy or backwards compatibility cases where this cannot be done. PSScriptAnalyzer has a suppression feature that can be used to document the reason for it in your code.

Thanks to Michael Van Leeuwen (GitHub user MJVL) for contributing this rule.

Enhancements

Invoke-Formatter now accepts input via the pipeline, either just as a string or [pscustomobject] with parameter values.

The AvoidUsingPlainTextForPassword rule is the first built-in rule to now return more than one suggestion for correction. In addition to suggesting the usage of SecureString, it now offers an alternative suggestion with PSCredential.

With version 2.40.0 of the az CLI, its entrypoint changed from a batch script to an az.ps1 script. Since this script just passed its received arguments as $args as-is to python, it is still a CLI and not a script with parameters. But it causes now a AvoidUsingPositionalParameters warning, which is a false positive. We therefore added a CommandAllowList configuration to it, which has az in it by default.

Documentation changes

In order to keep documentation all consolidated in one location, we have moved the documentation in the repo to the repo of docs.microsoft.com. Please see the documentation notice in the repo in order to get more specific details.

Outlook

Expect more formatting rules and options in the next release and continue giving us feedback. We are looking to increase our release frequency now that the Microsoft internal build has moved to a new system, which is what caused some delay to this release. To reduce maintenance, we are looking to drop support for PowerShell version 3 and 4 in future versions of PSScriptAnalyzer, which would also align it with the PowerShell extension for Visual Studio Code where this change was successful. The first step could be to increase the value of the PowerShellVersion property in the module manifest but still ship the version specific binaries so that it would still work if one changed its value in the manifest.

On behalf of the Script Analyzer team,

Christoph Bergmeister, Project Maintainer from the community, Avanade

Jim Truher, Senior Software Engineer, PowerShell Team, Microsoft

Jim Truher Senior Software Engineer, PowerShell

Follow