-
Notifications
You must be signed in to change notification settings - Fork 1
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
"Cannot find an overload for ".ctor" and the argument count: "1"" error in Invoke-Analyzer (OSOE-560) #28
Comments
It's related to PowerShell/PSScriptAnalyzer#1881 and should've been fixed as of 21203aa. |
I see, thanks! @BenedekFarkas could you please chime in too? |
I don't have a repro on the latest dev branch, even with a purged repo. Running the analysis manually in pwsh is also error-free. The base library was updated to 1.21 in #20 - do you have an earlier version installed too? If so, please try removing it (check both powershell and pwsh). |
So, you don't have earlier versions installed anymore? From either Windows PS or PS Core? |
Oh, wait. What you linked above (#24) is not actually a bugfix, just a cosmetic change. There was a bugfix related to suppress messages, but in Utility Scripts: Lombiq/Utility-Scripts@96027b5 So, make sure that you use the latest dev of Infrastructure/Utility Scripts. If that's still not working, then you can modify |
I had 1.20.0 installed in Windows PowerShell, but I don't see how that would make a difference. In any case, uninstalling it and running the command in Pwsh 7 as I did above still yields the same result. I don't understand why Utility Scripts affects this, but pulling in its latest does change the error to: Changing $results = Find-Recursively -IncludeFile '*.ps1', '*.psm1', '*.psd1' -ExcludeDirectory node_modules |
Where-Object { # Exclude /TestSolutions/Violate-Analyzers.ps1 and /TestSolutions/*/Violate-Analyzers.ps1
$IncludeTestSolutions -or -not (
$PSItem.Name -eq 'Violate-Analyzers.ps1' -and
($PSItem.Directory.Name -eq 'TestSolutions' -or $PSItem.Directory.Parent.Name -eq 'TestSolutions')) } |
ForEach-Object { Invoke-ScriptAnalyzer -Path $PSItem.FullName @analyzerParameters }
foreach ($result in $results)
{
$message = $result.RuleName + ': ' + $result.Message
Write-FileError -Path $result.ScriptPath -Line $result.Line -Column $result.Column $message
} to $results = Find-Recursively -IncludeFile '*.ps1', '*.psm1', '*.psd1' -ExcludeDirectory node_modules |
Where-Object { # Exclude /TestSolutions/Violate-Analyzers.ps1 and /TestSolutions/*/Violate-Analyzers.ps1
$IncludeTestSolutions -or -not (
$PSItem.Name -eq 'Violate-Analyzers.ps1' -and
($PSItem.Directory.Name -eq 'TestSolutions' -or $PSItem.Directory.Parent.Name -eq 'TestSolutions')) }
foreach ($result in $results)
{
Write-Output $result.FullName
Invoke-ScriptAnalyzer -Path $result.FullName @analyzerParameters
} as a test yields this: But! If I then change the script back to the original version, it runs to completion without errors (or without any output, really). Cleaning the repo doesn't change this either. WTF? |
To eliminate the differences between our environments and I've seen inconsistent behavior with multiple versions installed (especially with the two different PS versions). You don't need the older version installed anyway.
Utility Scripts is related due to the issue Dávid linked above that I opened: PowerShell/PSScriptAnalyzer#1881 The symptom there was that we were analyzing scripts in OSOCE and one of them calls
Now that sort of inconsistency is not something I've seen. Can you please try changing the evaulation of
|
I still don't have a local repro, but I've seen this pop up in GHA for Utility Scripts and Infrastructure Scripts. Re-running the failed workflow "fixed" it though, so it's hard to infer anything from it... |
The NRE I mentioned above happens semi-regularly in OSOCE. Most recent is here. As a band-aid solution, we could have a |
After some time since the issue was reported, are you still able to reproduce it, @Piedone? I've been trying to do so but without success. The Some details of my environment:
I suspect that the set of files being analyzed may differ, being one of them a possible trigger of the issue. If I run the following snippet from the original script:
I get this list of files subject to analysis:
Can you spot any difference, @Piedone? PD: EDIT At least file |
Yep, it happens randomly in OSOCE GHA builds. Seen it like two days ago too. |
For one try (building locally), I couldn't reproduce it. But I guess this is because it happens randomly as Zoltán said. |
Here's the recent example I mentioned: https://github.com/Lombiq/Open-Source-Orchard-Core-Extensions/actions/runs/6589654527/job/17904585730#step:12:20 |
Nice, thank you @Piedone. Regarding running it locally, is it still reproducible for you like it was here? If so, does it happen every time you run the script or also "randomly" like in GHA? Would like to involve @DAud-IcI as well, since he's the other person experiencing this locally back then. |
I never tried to reproduce this specifically locally but it did happen randomly before, see my earlier comments. However, I don't think it's much use trying to do that: this is a |
Sorry, to be honest I don't remember anything about this. At the moment I can't reproduce it either. I'll remember to write more context in the future. |
Hmm. Despiste having the retries working when running the script locally, it seems the execution stops on GHA when encountering the first May GHA be configured somewhere to immediately stop when a |
Hmm, that could be down to ErrorActionPreference. |
Before changing any configuration related to And then see if any error comes up again after a couple of days when running from GHA. |
Now that you mention it, it makes more sense to me anyway to use |
Looks good, I'm merging the things, we will wait and see if any error comes up again. |
Invoke-Analyzer
:This is the same error as the one fixed in #24, but the offending line has nothing to do with
SuppressMessage
:https://github.com/Lombiq/PowerShell-Analyzers/blob/dev/Lombiq.Analyzers.PowerShell/Invoke-Analyzer.ps1#L119
Jira issue
The text was updated successfully, but these errors were encountered: