mikefrobbins
commented
9 years ago It appears that when the PSReadLine module is imported it causes the difference in the PowerShell console where a trailing backslash is added when tab expanding folder paths. Trailing backslashes are not added by default in the PowerShell console until that particular module is imported.
This explains the behavior differences in the ISE and the console, but the custom rules path for script analyzer should be able to handle a trailing backslash regardless.
kapilmb
When a trailing backslash is added to the end of the path for custom script analyzer rules, the rules are not tested. Example:
Invoke-ScriptAnalyzer -Path C:\tmp\MyScript.ps1 -CustomizedRulePath C:\tmp\CommunityAnalyzerRules\
Specifying a custom rule path without a trailing backslash or using a path directly to the PSD1 module manifest file for the custom rules works without issue. The problem though is that the console and ISE behave differently when tab expanding folder paths. In the ISE, a trailing backslash is not added by default, but in the PowerShell console a trailing backslash is added by default when tab expanding a folder path.
The Get-ScriptAnalyzerRule cmdlet also has this same trailing backslash problem:
These work: Get-ScriptAnalyzerRule -CustomizedRulePath C:\tmp\CommunityAnalyzerRules
Get-ScriptAnalyzerRule -CustomizedRulePath C:\tmp\CommunityAnalyzerRules\CommunityAnalyzerRules.psd1
This does NOT work: Get-ScriptAnalyzerRule -CustomizedRulePath C:\tmp\CommunityAnalyzerRules\
There are no errors generated. It's like the rules don't exist when a trailing backslash is specified. I also tested specifying an invalid path to custom rules that does not exist and no errors are generated in that scenario either. Based on how other cmdlets work, I would expect an error to be generated when an invalid path to custom rules is specified.
These tests were performed on Windows 10 Enterprise Edition with PowerShell version 5.0.10240.16384