PSScriptAnalyzer fails to find types

[chriskuech]

I have working code containing at the top:

using namespace Microsoft.Azure.Commands.ResourceManager.Cmdlets.SdkModels
using namespace Microsoft.Azure.Commands.Common.Authentication.Abstractions

Import-Module "AzureRm"

In the middle of my code I define variables of type [IStorageContext] and [PSResourceGroupDeployment]. When the script opens in VS Code, these types are flagged as not found by PSScriptAnalyzer, but found after changes. Similarly, this same code is being flagged by PSScriptAnalyzer in PowerShell Gallery.

[bergmeister]

@chriskuech I cannot repro by putting the following content into a file.ps1 file and running Invoke-ScriptAnalyser .\file.ps1 (or opening it in the latest version of VSCode):

using namespace Microsoft.Azure.Commands.ResourceManager.Cmdlets.SdkModels
using namespace Microsoft.Azure.Commands.Common.Authentication.Abstractions

Import-Module "AzureRm"

[IStorageContext]$storageContext = Get-StorageContext
[PSResourceGroupDeployment]$psResourceGroupDeployment = Get-PSResourceGroupDeployment

[chriskuech]

Can you try and repro by opening Types.ps1 in GitHub.com/Microsoft/cluster ? I discovered this issue from a false positive automated PSGallery email from @tyler<mailto:tyleonha@microsoft.com>, for whom this may be of interest. Thanks, Chris Get Outlook for Android<https://aka.ms/ghei36>

…

________________________________ From: Christoph Bergmeister <notifications@github.com> Sent: Sunday, January 21, 2018 11:25:18 AM To: PowerShell/PSScriptAnalyzer Cc: Chris Kuech; Mention Subject: Re: [PowerShell/PSScriptAnalyzer] PSScriptAnalyzer fails to find types (#850) @chriskuech<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fchriskuech&data=02%7C01%7CChris.Kuech%40microsoft.com%7Ce7f93bad8ed44f12d60f08d560c1a70b%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636521307216374439&sdata=%2Babhx%2Fsv%2FNz%2Frt48VEwv%2F2iCTeiNuOGFwrQ7j6VGJig%3D&reserved=0> I cannot repro by putting the following content into a file.ps1 file and running Invoke-ScriptAnalyser .\file.ps1 (or opening it in the latest version of VSCode): using namespace Microsoft.Azure.Commands.ResourceManager.Cmdlets.SdkModels using namespace Microsoft.Azure.Commands.Common.Authentication.Abstractions Import-Module "AzureRm" [IStorageContext]$storageContext = Get-StorageContext [PSResourceGroupDeployment]$psResourceGroupDeployment = Get-PSResourceGroupDeployment — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FPowerShell%2FPSScriptAnalyzer%2Fissues%2F850%23issuecomment-359241263&data=02%7C01%7CChris.Kuech%40microsoft.com%7Ce7f93bad8ed44f12d60f08d560c1a70b%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636521307216374439&sdata=LN%2BbYL6alB4yug45YNZAcXY1XklU3NHOnxhwa4MyFEc%3D&reserved=0>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADgpnzkQnZ4eq6k9USms33gqV8tjU824ks5tMx6egaJpZM4Rj6Wm&data=02%7C01%7CChris.Kuech%40microsoft.com%7Ce7f93bad8ed44f12d60f08d560c1a70b%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636521307216374439&sdata=L0Y4uhn%2BNmddYec8%2FbNSpR9i7jF2HROaRc%2ByxlzI8g8%3D&reserved=0>.

[bergmeister]

It reproes now using the referenced Types.ps1 file. The Tyler that you wanted to reference is not @tyler but @tylerl0706 .
A minimal, complete and verifiable example is:

using namespace Microsoft.Azure.Commands.ResourceManager.Cmdlets.SdkModels
using namespace Microsoft.Azure.Commands.Common.Authentication.Abstractions
Import-Module "AzureRm"
class MyClass { [IStorageContext]$StorageContext }

It seems to be an issue related to the variable being inside a class because the following makes no problems if it is not inside a class
The parse error happens on this line here:

scriptAst = Parser.ParseInput(scriptDefinition, out scriptTokens, out errors);

[SeeminglyScience]

@bergmeister Type resolution inside classes is done at parse time, outside of classes it's done at run time. This happens because the classes aren't loaded initially. Once they are loaded (either through automatically importing for command completion or manually imported) the syntax markers disappear.

How this is supposed to work is you either include the module in your required modules/assemblies manifest field or include a using module/assembly x statement. That said, these will load the module/assembly needed but the parser doesn't currently attempt to actually determine what types they contain.

Related issues #559, PowerShell/PowerShell#2074, PowerShell/PowerShell#3641

[smurawski]

We (myself and @DarqueWarrior) are also seeing this behavior on the VSTeam module which relies on the SHiPS module.

[bergmeister]

Thanks @SeeminglyScience for providing the related issues. It seems that this is mainly caused by a not yet implemented feature in PowerShell's parser. There seems to be already an existing PR (referenced below) for it. I enquired about its timeline so that we can make a decision whether PSSA needs to workaround this external issue or if a fix arrives in a reasonable time in the PowerShell reference binaries. I know that we all want things fixed ASAP but it might be helpful, if people comment what kind of timeline would be acceptable/reasonable.

[bergmeister]

@SeeminglyScience @smurawski Some positive news: I figured out that PSSA has its own, self-contained version of the parser and therefore we do not depend on the parser of the PowerShell instance that calls PSSA. A pull request with the added language feature is going to be finished in about 1 month and I have requested an updated version of a the System.Management.Automation Nuget package of powershell-core to PSSA uses to get the updated parser.
To prove my point, I created a prototype where I parse a script on an Ubuntu machine that does not even have PowerShell installed at all (only the .net core runtime).

[bergmeister]

Some updates: the PowerShell team is not planning to implement the required parser feature. We will either have build our own custom parser or as a workaround for the moment try to catch the specific error and try to remove the unknown object type in memory before parsing the script content