{"id":81905,"date":"2017-01-31T00:01:25","date_gmt":"2017-01-31T08:01:25","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/heyscriptingguy\/?p=81905"},"modified":"2019-02-18T09:10:14","modified_gmt":"2019-02-18T16:10:14","slug":"psscriptanalyzer-deep-dive-part-1-of-4","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/scripting\/psscriptanalyzer-deep-dive-part-1-of-4\/","title":{"rendered":"PSScriptAnalyzer deep dive \u2013 Part 1 of 4"},"content":{"rendered":"

Summary<\/strong>: Thomas Rayner, Microsoft Cloud and Datacenter Management MVP, shows the basics about how to use PSScriptAnalyzer.<\/p>\n

Hello! I\u2019m Thomas Rayner, a Cloud and Datacenter Management Microsoft MVP, filling in for The Scripting Guy this week. You can find me on Twitter (@MrThomasRayner<\/a>), or posting on my blog, workingsysadmin.com<\/a>. This week, I\u2019m presenting a four-part series about how to use PSScriptAnalyzer.<\/p>\n

Part 1 \u2013 Getting started with PSScriptAnalyzer<\/p>\n

Part 2 \u2013 Suppressing, including, excluding rules<\/a><\/p>\n

Part 3 – Wrapping PSScriptAnalyzer with Pester to get formatted results<\/a><\/p>\n

Part 4 \u2013 Writing custom rules<\/a><\/p>\n

This is Part 1, so I\u2019m going to introduce you to PSScriptAnalyzer and show you how to get started.<\/p>\n

PSScriptAnalyzer (or PSSA), is an open-source tool that Microsoft developed. Its source code is hosted on GitHub<\/a>. The purpose of PSSA is to offer a tool that checks PowerShell code against a set of rules based on best practices. It comes with a bunch of built-in rules and you can add your own.<\/p>\n

The default PSSA rules, which cover a wide variety of best practices, are an excellent starting place. Just to mention a few: PSSA will check your script and warn you about using aliases instead of the full name of a command, using Invoke-Expression<\/code> and other dangerous cmdlets, naming your functions correctly, and a whole lot more.<\/p>\n

So, how do you get started? First, you need to install the PSScriptAnalyzer module.<\/p>\n

Install-Module -Name PSScriptAnalyzer -Scope CurrentUser<\/code><\/p>\n

You can verify that the PSSA module was installed by running the following command.<\/p>\n

Get-Module -Name PSScriptAnalyzer -ListAvailable<\/code><\/p>\n

And you\u2019ll get output like this:<\/p>\n

\"Verification<\/a><\/p>\n

Now, you just need to import the module so you can use it.<\/p>\n

Import-Module -Name PSScriptAnalyzer<\/code><\/p>\n

Like with any module, you can easily explore all the commands that it brings into your session.<\/p>\n

Get-Command -Module PSScriptAnalyzer<\/code><\/p>\n

There are only two: Get-ScriptAnalyzerRule<\/code> and Invoke-ScriptAnalyzer<\/code>. We\u2019re going to look at Get-ScriptAnalyzerRule another time.<\/p>\n

Now you are ready to run your first test. It\u2019s as easy as running Invoke-ScriptAnalyzer and specifying a path to a script. In this example, I have a script named \u201cMyScript.ps1\u201d whose contents are as follows.<\/p>\n

param (<\/code><\/p>\n

$Path,\n$DaysOld<\/code>\n)<\/code><\/p>\n

$someVar = $null<\/code><\/p>\n

Write-Host \"Counting items...\"<\/code><\/p>\n

$itemCount = (gci $Path | ? { $_.LastWriteTime -gt (Get-Date).AddDays(-$DaysOld)}).Count<\/code><\/p>\n

Write-Host \"There are $itemCount items\"<\/code><\/p>\n

The script takes a path to a directory and gets all the items that have been written more than the specified number of days ago. You might be able to tell that there are some problems with this script already, just by looking at it. Let\u2019s see what PSSA says.<\/p>\n

I can run Invoke-ScriptAnalyzer<\/code> on my script\u2026<\/p>\n

Invoke-ScriptAnalyzer -Path .\\MyScript.ps1<\/code><\/p>\n

\u2026 and see that there are some glaring violation of best practices.<\/p>\n

\"Result<\/a><\/p>\n

As you can tell, there\u2019s a bunch of problems here. It looks like my script violates the following rules:<\/p>\n