TypeNotFound when using classes

[abelal83]

Steps to reproduce

class SecretComparer : System.Collections.IComparer {
    
    [int] $ChangeInDays = 7

    [bool] ShouldChangeSecret() {

        #throw "method not implemented"
        return $true
    }

    # this will compare if the secret is same
    [int] Compare([object] $obja, [object] $objb) {

        throw "method not implemented"
    }

}

using module .\Clarksons.Scripts.PlatformEngineering.DevsKeyVault.SecretComparer.psm1

class KeyVault {
    
    [string] $KeyVaultName

    KeyVault([string] $KeyVaultName, [SecretComparer] $comparer) {
    
        write-host $comparer
    }

}

$t = [SecretComparer]::new()
$x = [KeyVault]::new('gfdgfd', $t)

Expected behavior

This message should not appear as I'm loading classes into the sessions

Actual behavior

If an unexpected error was thrown then please report the full error details using e.g. $error[0] | Select-Object *

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.14393.693
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.693
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

> (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }
1.17.1

[bergmeister]

This is by design and a limitation of the PowerShell parser, not PSScriptAnalyzer. In the future, we should address #1041 though and return a warning instead of a diagnostic record for Parser exceptions. cc @rjmholt

[abelal83]

Apols if this is a simple answer but how do I get around this in vscode? Right now I have several dozen green files in an otherwise clean powershell library due to this issue. I simply want to stop the files being displayed as having problems.

[bergmeister]

@abelal83 This is what issue #1041 is about: Currently those warnings cannot be suppressed other than filtered out via command line. Previously, PSSA failed completely, hence why it was decided to accept graceful parser errors but still display them as warnings to the user that only a part of the script could be analysed due to the limitation of the parser (PSSA completely relies on the parser in order to do its work). In hindsight, it was a mistake to return an object, which is being displayed as an issue in VSCode instead of just returning a warning and let VSCode deal with the display of the warning.

[abelal83]

@bergmeister gotcha, thank you for explaining.