nasm - error when upgrading

[Destroy666x]

Describe the bug
Upgrading nasm package causes this error:
ERROR: Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'NewName'. Specified method is not supported.

To Reproduce
Steps to reproduce the behavior:

1. Upgrade non-latest nasm package

Expected behavior
No error.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Choco: latest

Additional context
Log:

2022-12-31 06:41:26,946 21632 [ERROR] - ERROR: Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'NewName'. Specified method is not supported.
2022-12-31 06:41:26,950 21632 [DEBUG] - Built-in PowerShell host called with ['[System.Threading.Thread]::CurrentThread.CurrentCulture = '';[System.Threading.Thread]::CurrentThread.CurrentUICulture = ''; & import-module -name 'C:\ProgramData\chocolatey\helpers\chocolateyInstaller.psm1'; & 'C:\ProgramData\chocolatey\helpers\chocolateyScriptRunner.ps1' -packageScript 'C:\ProgramData\chocolatey\lib\nasm\tools\chocolateyinstall.ps1' -installArguments '' -packageParameters '' -preRunHookScripts $null -postRunHookScripts $null'] exited with '-1'.

[teknowledgist]

Hi. Based on your report, I am guessing that the newer version of nasm is installed (even if Chocolatey thinks it isn't). Is that correct?

Thanks.

[teknowledgist]

I just upgraded from 2.14.02 to 2.16.01 and did not get that error. Do you know what version you were upgrading from to get the error?

[Destroy666x]

From 2.15.05 to latest.

According to nasm -v it got upgraded indeed, I'm prett sure this line fails: https://github.com/teknowledgist/Chocolatey-packages/blob/master/automatic/nasm/tools/chocolateyinstall.ps1#L31 Since I have 2 folders matching that - 1 renamed earlier during initial install and one called Netwide Assembler 2.15.05. So that's why it's an array.

Isn't the solution just deleting Netwide Assembler dir before renaming the new one that includes version? It worked as a workaround at least. Or perhaps more advanced matching for Get-ChildItem that considers the version with a regex.

[teknowledgist]

Sure. That is the solution. In my testing, I didn't see the need to check for more than one folder because of the installer behavior. If there was no folder, it would place one with the version number. If there was a folder, it would leave it alone. On upgrades, the folder would continue to have the old version number. If I removed the version number, the installer would again just leave it alone.

I'm surprised that the upgrade left the old Start Menu folder and created a new one.

I'll work on a fix. Thanks for reporting it.