Vscode-powershell: PowerShell: Non-standard verb causes squiggly lines throughout entire function

[pcgeek86]

• VSCode Version: 0.10.13-insider
• OS Version: Windows 10 Version 1511

Steps to Reproduce:

1. Install PowerShell Extension
2. Write a function that uses an "unapproved" verb
3. Notice the excessive squiggly lines

@daviwil

Cheers,
Trevor Sullivan
https://trevorsullivan.net
https://twitter.com/pcgeek86

https://github.com/Microsoft/vscode/issues/4816

[rkeithhill]

Which version of the extension are you using? I can't duplicate this with 0.5.0. There was an update to PSScriptAnalyzer to address this issue for a few rules (using approved verb was one of those). That updated version of PSScriptAnalyzer got pulled into the 0.4.1 release. So with 0.4.1 and higher, you shouldn't see this issue.

[daviwil]

I was speaking to Trevor about this on the original Microsoft/vscode issue, we confirmed that he's using 0.5.0. That's really confusing because like you say, this issue has been fixed for a while now. In this case it seems like the old PSScriptAnalyzer rules assembly is being used but I'm not sure how that's even possible...

[rkeithhill]

@pcgeek86 Can you repro the problem and then grab the handle SysInternals tool. Open an elevated prompt and run handle.exe Microsoft.Windows.PowerShell.ScriptAnalyzer and post the output here.

That will tell us the path of the ScriptAnalyzer dll that is loaded into the PSES host. It would also help to only have one VSCode instance running when you do this. Thanks.

[pcgeek86]

@rkeithhill @daviwil Here you go folks -- any thoughts?

[dsolodow]

I'm able to re-produce it as well;
Windows 10 build 14295 x64
Code 0.10.11
PowerShell extension 0.5.0

C:\Users\Damien.vscode\extensions\ms-vscode.PowerShell-0.5.0\bin\Microsoft.Windows.PowerShell.ScriptAnalyzer.dll
C:\Users\Damien.vscode\extensions\ms-vscode.PowerShell-0.5.0\bin\Microsoft.Windows.PowerShell.ScriptAnalyzer.BuiltinRules.dll

[rkeithhill]

OK I can repro it now. BTW as soon as I put one blank line before this function definition, we start getting back the correct extent from PSScriptAnalyzer. Weird, bizarre and quite strange also.

[pcgeek86]

@rkeithhill Nice -- glad the repro worked out. /cc @dsolodow

[daviwil]

Seems to be a bug in the rule, I can repro it also if I define the function at the very top of the file without a newline before it. Nice catch Trevor and Damien! I've filed an issue (https://github.com/PowerShell/PSScriptAnalyzer/issues/492) so the PSScriptAnalyzer team can take a look.

[daviwil]

@kapilmb has already got a fix prepared for this issue: https://github.com/PowerShell/PSScriptAnalyzer/pull/495. It'll be in the next PSScriptAnalyzer update. I'll see if we can sync that up with the next VS Code extension release.

I'll keep this bug open until we verify that it works on our end for the next release.

[daviwil]

Still waiting on a new PSScriptAnalyzer update before this issue can be fixed. I'm going to bump this to 0.7.0 under the condition that 0.7.0 will come out soon after 0.6.0 and be primarily focused on a couple of PSScriptAnalyzer-related improvements.

[ian-moore]

I have this problem too but with a different analyzer warning, I'm not sure if it's related or maybe I don't understand the rule?

[daviwil]

@kapilmb do you know if the ShouldProcess rule has also been fixed with the extent checking that doesn't make it mark the whole file?

[rkeithhill]

@ian-moore Is this the first function in the file? If so, as a workaround, put a blank line before the function. You also see to have a file encoding issue as indicated by the ? in diamond character before the [CmdletBinding] attribute.

[kapilmb]

This appears to be PSShouldProcess rule violation. As of now, the violation extent of this rule marks the entire function :( - https://github.com/PowerShell/PSScriptAnalyzer/blob/development/Rules/UseShouldProcessCorrectly.cs#L67

[ian-moore]

I'm not exactly sure what I updated today, but I no longer receive the warning, even before removing the invalid character. Thanks for the help though!

[daviwil]

This one has been fixed for a while, just forgot to close the bug!