Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PSScriptAnalyzer fails to find types #850

Closed
chriskuech opened this issue Jan 19, 2018 · 8 comments · Fixed by #957
Closed

PSScriptAnalyzer fails to find types #850

chriskuech opened this issue Jan 19, 2018 · 8 comments · Fixed by #957
Assignees

Comments

@chriskuech
Copy link

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
Copy link
Collaborator

@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
Copy link
Author

chriskuech commented Jan 21, 2018 via email

@bergmeister
Copy link
Collaborator

bergmeister commented Jan 21, 2018

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
Copy link
Contributor

@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
Copy link

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

@bergmeister
Copy link
Collaborator

bergmeister commented Feb 18, 2018

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
Copy link
Collaborator

bergmeister commented Mar 3, 2018

@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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants