PSScriptAnalyzer (PSSA) 1.21.0 has been released

Jim Truher

October 24th, 20223 1

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.0reached 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 moreinformation about supported versions of PowerShell, see thePowerShell 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 notimpact 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 acceptsas 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 inmost PowerShell scripts and can be omitted. This rule is not enabled by default and can be used byInvoke-Formatter.

The latest Preview version of the PowerShell extension for Visual Studio Code already includesPSScriptAnalyzer 1.21.0 and can control this formatting rule via a newpowershell.codeFormatting.avoidSemicolonsAsLineTerminators setting. This should soon be availablein 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 valueto the -Algorithm parameter since those algorithms are no longer considered secure. Usersshould consider replacing the value with SHA256, SHA384, SHA512, or other safer algorithmswhere possible. It is understood there will be legacy or backwards compatibility cases where thiscannot be done. PSScriptAnalyzer has a suppression feature that can be used to document thereason 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 onesuggestion for correction. In addition to suggesting the usage of SecureString, it now offersan alternative suggestion with PSCredential.

With version 2.40.0 of the az CLI, its entrypoint changed from a batch script to an az.ps1script. Since this script just passed its received arguments as $args as-is to python, it is stilla CLI and not a script with parameters. But it causes now a AvoidUsingPositionalParameterswarning, 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 inthe repo to the repo of docs.microsoft.com. Please see the documentation notice in therepo in order to get more specific details.

Outlook

Expect more formatting rules and options in the next release and continue giving us feedback. We arelooking to increase our release frequency now that the Microsoft internal build has moved to a newsystem, which is what caused some delay to this release. To reduce maintenance, we are looking todrop support for PowerShell version 3 and 4 in future versions of PSScriptAnalyzer, which would alsoalign it with the PowerShell extension for Visual Studio Code where this change was successful. Thefirst step could be to increase the value of the PowerShellVersion property in the module manifestbut still ship the version specific binaries so that it would still work if one changed its value inthe 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