PSScriptAnalyzer: a rule-based static checker for PowerShell that needs a .NET 8 SDK to build from source

Rules produce DiagnosticResults, and the built-in set catches things like Invoke-Expression

PSScriptAnalyzer is a static code checker for PowerShell modules and scripts. It runs a set of rules based on PowerShell best practices identified by the PowerShell Team and the community, and it generates DiagnosticResults, which are errors and warnings. Each result also suggests a possible improvement.

The README names three of the built-in checks as examples: the presence of uninitialized variables, use of the PSCredential type and use of Invoke-Expression. The list ends with and many more, so the full set is in the rules documentation.

To see what is installed on your machine, run Get-ScriptAnalyzerRule in the PowerShell console. The README gives that command as the way to confirm an installation, and it returns the built-in rules.

The tool is static. It reads the code and does not run it, so a rule can flag a risky pattern, but it cannot tell you whether the script behaves correctly at run time.

Install-Module is the whole install for most users

From the PowerShell Gallery the install is one command run in a PowerShell terminal:

Install-Module -Name PSScriptAnalyzer

The README also points to an Installing PSScriptAnalyzer section on learn.microsoft.com for the same route. The repository description reads Download ScriptAnalyzer from PowerShellGallery, which is the project's own pointer to that channel.

The latest release is 1.25.0 from 2026-03-20, followed by 1.24.0 from 2025-03-18 and 1.23.0 from 2024-10-09. Each of the three releases is about a year after the one before it, so check the gallery for the current version before you pin one.

The last push to the repository was on 2026-10-23, and it is not archived. The licence is MIT.

Building from source asks for the .NET 8.0 SDK, Pester v6 and PlatyPS

Source builds have a longer requirements list. The README names the latest .NET 8.0 SDK, and the .NET Framework 4.6.2 targeting pack if you are building for Windows PowerShell versions, which is only possible on Windows. Visual Studio 2022 or Visual Studio Code are optional but recommended for development. The Pester v6 and PlatyPS PowerShell modules are also required.

The steps start with the source. Download it from the release page, or clone the repository with git:

git clone https://github.com/PowerShell/PSScriptAnalyzer

Then move into the directory and build:

cd path/to/PSScriptAnalyzer

The targeting pack can only be installed on Windows, so building for Windows PowerShell versions needs a Windows machine.

The repository contains PSScriptAnalyzer.sln, build.ps1, build.psm1, global.json and the folders Engine, Rules, Tests, Utils, PSCompatibilityCollector and docs.

build.ps1 builds for the current PowerShell by default, with flags for 5, 7, documentation and all

You can build from the Visual Studio solution or from PowerShell. The default build targets the version of PowerShell you are currently running:

.\build.ps1

For Windows PowerShell version 5.0:

.\build.ps1 -PSVersion 5

For PowerShell 7:

.\build.ps1 -PSVersion 7

Documentation builds automatically only the first time, so rebuild it after changing help content:

.\build.ps1 -Documentation

To build both versions and the documentation in one go, use -All:

.\build.ps1 -All

Then import the module from the out folder:

Import-Module .\out\PSScriptAnalyzer\[version]\PSScriptAnalyzer.psd1

The documentation caveat is easy to miss, because a second plain build does not rebuild it.

Resource strings should be edited in Visual Studio, not by hand

A contributor adding or removing resource strings in the resx files runs into a specific trap. The README recommends Visual Studio for this, because it automatically updates the strongly typed Designer.cs files that go with each resx file.

Without Visual Studio there are two options. You can adapt the Designer.cs files manually, or use the New-StronglyTypedCsFileForResx.ps1 script, which sits in the repository root. The README discourages the script because it leads to a bad diff of the Designer.cs files, which makes pull requests harder to review.

The same paragraph mentions the free Visual Studio 2017 Community Edition, while the requirements list recommends Visual Studio 2022.

For anyone only running the analyzer, none of this applies.

Tests run through Pester 6 and build.psm1 helpers

The Pester-based tests live in the Tests folder. Pester of at least version 6.0 must be installed, and the run starts from the root of your local repository:

./build -Test

The results come from helpers in the build module. Import build.psm1 and call Get-TestResults:

Import-Module ./build.psm1
Get-TestResults

To see only failures, use Get-TestFailures after the same import:

Import-Module ./build.psm1
Get-TestFailures

The README does not state how long the suite takes or how many tests it holds.

Contributions go through issues first. The README asks you to discuss a fix or feature in an issue before submitting a pull request.

User documentation lives on learn.microsoft.com, and only the latest release is published there

A documentation notice explains a recent move. Conceptual user documentation left the source repository for a documentation repository so it can be published on learn.microsoft.com. The source repository keeps only documentation about the code base, such as building and contributing.

The notice maps the old files to new pages. Most of this README is now the PSScriptAnalyzer overview page. The cmdlet reference and the rules overview have their own pages. PowerShellBestPractices.md became PSScriptAnalyzer rules and recommendations, and ScriptRuleDocumentation.md became Creating custom rules. The Using PSScriptAnalyzer section of this README is a link to the page of the same name.

There is one exception. The rule and cmdlet documentation stays in the docs folder, so it can be build-tested and archived with each release. Only the latest release's documentation is published on learn.microsoft.com.

If you run an older release, the published pages may describe rules your version lacks, and the docs folder at that release tag is the matching source.

Editorial conclusion

Install PSScriptAnalyzer from the PowerShell Gallery if you want rule-based linting of PowerShell modules and scripts, and build from source only when you contribute to it. It will not tell you how your code runs, because it checks quality rules and not behaviour. Before building, check that you have the .NET 8.0 SDK and, for Windows PowerShell targets, the .NET Framework 4.6.2 targeting pack.

Frequently asked questions

Official sources

1. License: MIT
2. PowerShell/PSScriptAnalyzer on GitHub
3. Project website
4. README
5. Releases