Silent Args being passed as a string array cause package failure

[ferventcoder]

First bug to come out of #697. https://chocolatey.org/docs/helpers-install-chocolatey-package#parameters SilentArgs is now strictly a string instead of left up for interpretation. Most items were converted in this way to provide clarity.

https://chocolatey.org/packages/OpenSSL.Light#files - chocolateyInstall.ps1:

 silentArgs = '/silent', '/verysilent', '/sp-', '/suppressmsgboxes',
    "/DIR=`"$installDir`"";

Results in:

ERROR: Cannot process argument transformation on parameter 'silentArgs'. Cannot convert value to type System.String.
The install of openssl.light was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\OpenSSL.Light\tools\chocolateyInstall.ps1'.

[ferventcoder]

Is this something we fix or state that the package should not have done things in a non-compliant way?

[jberezanski]

Was it documented anywhere that silentArgs should have been a single string?

[ferventcoder]

Yes - in all examples and in the old documentation for the last five
years we've said it was a string value.

You can look at the older wiki docs and the history of those wiki pages to
see this.

On Saturday, June 18, 2016, Jakub Berezanski notifications@github.com
wrote:

Was it documented anywhere that silentArgs should have been a single
string?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#808 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAD4DqDcmxSRT4fzcwB_khJ5gWTUha5iks5qNDqogaJpZM4I4wPz
.

Rob
"Be passionate in all you do"

http://codebetter.com/robreynolds
http://ferventcoder.com
https://twitter.com/ferventcoder

[jberezanski]

Ah, indeed, forgot about the wiki for a moment.
I examined the history of Install-ChocolateyPackage. The mention of a string data type only appeared after you turned on auto doc on April 12. In all earlier revisions, the description of the parameter did not specify the type, only the interpretation. The example did show a single string value, but it did not necessarily mean that an array of strings was invalid.
I agree, though, that the intent of the documentation was that it should have been a simple string. In that light, I'd say leave it as-is.

However, perhaps this is a good time for a small official usability improvement? Changing the parameter to a string[] would be a backward compatible change, I believe, and it would help packages with complex installer argument construction logic (such as Visual Studio) - those packages would be able to accumulate installer arguments in an array and pass it unmodified to the helper. This would also align the helper with existing PowerShell cmdlets which declare an ArgumentList parameter, where arguments are passed as an array (e.g. Invoke-Command, Start-Process, New-Object).

[ferventcoder]

As long as it is backwards compatible, 👍