Release of PowerShell Script Analyzer (PSScriptAnalyzer) 1.18.2
In keeping with the tradition of releasing improvements to
PSScriptAnalyzer more often, we’re happy to announce that 1.18.12 is now available! As a dependency of PowerShell Editor Services (a module used by editor extensions like the PowerShell Visual Studio Code extension), this release is motivated by a desire to further stabilize our editor experience. At the moment, the Visual Studio Code PowerShell extension still ships with PSScriptAnalyzer
1.18.0. After fixing some undesirable edge cases between
1.18.2, we intend to ship an update to the Visual Studio Code extension that will include
The blocking issue that it resolves is quite technical and should not concern end-users, but for those who are interested: starting with
1.18.1, a performance optimization was added whereby we started to share and cache a PowerShell runspace pool instead of creating a new one for every command invocation. However, it turns out that there is an edge case where, when dealing with specific commands from the
PackageManagementmodule, the runspace pool can get into a deadlock, which causes the execution of PSScriptAnalyzer to hang indefinitely. This is due to a bug in
PackageManagementitself (a very unfortunate asynchronous API call that leads to the deadlock) but also PowerShell itself, which should be able to handle bad scenarios like this. Therefore, a workaround for this had to be implemented in PSScriptAnalyzer by blacklisting the PackageManagement commands.
Given that the other changes in this release are mainly fixes and small enhancements, we decided to not bump the minor version number. We ask that the community participate in testing and giving feedback on this update before it ships by default in the Visual Studio Code extension. You can make this new update with the Visual Studio Code extension start by executing the following command:
Install-Module -Name PSScriptAnalyzer -Repository PSGallery -Scope CurrentUser
Should you find that there are changes that you are not happy with, please report them here.
Optionally, you can roll back to the default included version of PSScriptAnalyzer by running
Uninstall-Module -Name PSScriptAnalyzer.
In this release, we’ve made the following fixes
PipelineIndentation: More edge cases when using non-default values of this setting (
NoIndentationin the Visual Studio Code extension) were fixed. This feature was only introduced in
1.18.0and we hope the be closer to a state now where we could potentially change the default.
- New compatibility rule profiles were added for non-Windows OSs on PowerShell 7 (preview). Additionally, fixes were made to profile generation to support macOS and Linux.
- A fix was made to
PSCloseBraceto correctly flag the closing brace of a one-line hashtable, correcting some broken formatting.
Enhancements were made in the following areas
- When using settings files, error messages are now much more actionable.
PS> Invoke-ScriptAnalyzer -Settings /tmp/MySettings.psd1 -ScriptDefinition 'gci' Invoke-ScriptAnalyzer : includerule is not a valid key in the settings hashtable. Valid keys are CustomRulePath, ExcludeRules, IncludeRules, IncludeDefaultRules, RecurseCustomRulePath, Rules and Severity. ...
- PSScriptAnalyzer has a logo now thanks to the community member @adilio
- The formatter was enhanced to also take commented lines into account in multi-line commands
- The formatter was enhanced to optionally allow correction of aliases as well. With this change, a setting in the Visual Studio Code extension will soon be made available to configure this. By default, this setting will not be on for the moment. We are open to feedback: while there are very likely a few people that would love for it to be enabled, it may upset others.
UseDeclaredVarsMoreThanAssignmentsnow also takes into account the usage of
Get-Variablewith an array of variables and usage of the named parameter
We’ve also made some changes in our GitHub repository and changed the default branch from
master to simplify the development workflow and be consistent with other repositories in the PowerShell organization. If you have a fork of the project, you will need to make this change in your fork as well or remember to use
master as a base and open pull requests against
master. This also means that the next version of the Visual Studio Code extension will point to
masterfor the documentation of PSScriptAnalyzer’s rules.
The Changelog has more details if you want to dig further.
We are thinking of following an approach similar to the Visual Studio Code extension where we make a version
2.0 at that drops support for
4. One of the next changes could be to improve how
PowerShellEditorServices calls into
PSScriptAnalyzer: currently, Editor Services uses the PSScriptAnalyzer PowerShell cmdlets which means that we have to create an entire instance of PowerShell for these invocations. Knowing that both
PSScriptAnalyzerare binary .NET modules, we could directly call into PSScriptAnalyzer’s .NET code by publishing a NuGet package of PSScriptAnalyzer with suitable public APIs. Given that PSScriptAnalzyer currently performs a conditional compilation for each PowerShell version (3, 4, 5, and 6+), dropping support for version 3 and 4 could help make the aforementioned move to an API model much easier to implement. Please give feedback if your use case of
PSScriptAnalyzerwould be impacted by this.
On behalf of the Script Analyzer team,
Christoph Bergmeister, Project Maintainer from the community, BJSS Jim Truher, Senior Software Engineer, Microsoft
I extensively use VSCode and PSScriptAnalyzer on Server 2008 R2.
We can debate all day as to whether I should or should not – but I can state without reservation that 2008 R2 is very common in “the real world”.
Regardless, I appreciate your efforts!
You can still use VSCode and PSScriptAnalyzer on Server 2008 R2, the only thing to do when support for v3 and v4 gets dropped at some point it to either upgrade the version of Windows PowerShell to 5.1 or install PowerShell Core, which works side by side without impacting other applications.
Note that Server 2008 R2 reaches the end of its extended support life-cycle in January 2020. From then on the only supported way to run this operating system would be to run it inside Azure where it would receive 3 additional years of Critical and Important security updates at no additional charge or via an (expensive) CSA (customer support agreement)
Also: VS-Code supports using an older version of an extension, so you will always be able to use the current version of the extension for your use cases, you will just not receive any new updates.
@Jim, I wonder if you made a typo in that part where you wrote:
“…dropping support for version 4 and 5 could help make the aforementioned move to an API model much easier to implement…”
Did you actually mean versions 3 and 4 instead?
Would dropping support for these versions affect compatibility rules for these?
Sorry, yes, in the 2nd statement it should’ve been version 3 and 4 only. When we say ‘dropping support’, we mean the PowerShell version that the user uses to run the module, therefore it does not affect compatibility rules at all.
The typo has been fixed now.
Hey!! Great article. Thanks for sharingZinfomatic Technologies