How to set a PowerShell switch parameter from TeamCity build configuration - powershell

Question

I have a PowerShell script with a switch (boolean) parameter that I want to call from a TeamCity build step.
I want the value of the switch (true/false) to be set according to a TeamCity build parameter, a configuration parameter.
So, something like this:
And in the PowerShell runner build step:
But the above does not work.
I get this error
[14:27:01][Step 1/1] Cannot process argument transformation on parameter 'preRelease'. Cannot
[14:27:01][Step 1/1] convert value "System.String" to type
[14:27:01][Step 1/1] "System.Management.Automation.SwitchParameter". Boolean parameters accept only
[14:27:01][Step 1/1] Boolean values and numbers, such as $True, $False, 1 or 0.
As you can see, it seems that PowerShell insist on interpreting the parameter as a string.
I have tried many variants of writing the script argument. None of these work:
-preRelease:%IncludePreRelease%
-preRelease:([boolean]%IncludePreRelease%)
-preRelease:([System.Convert]::ToBoolean(%IncludePreRelease%))

Answer 1

No, this still won't work. It seems that TC will always treat the value as a string no matter what. Maybe the answer was from a version of TC that allowed this, but the latest release does not.
Without colon:
[16:18:37]Step 1/6: Migrate Up (Powershell)
[16:18:37][Step 1/6] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
[16:18:37][Step 1/6] PowerShell arguments: [-NonInteractive, -ExecutionPolicy, ByPass, -File, C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1, "data\change scripts", DB, xxxxxxx, sa, *******, -NoExec, $false]
[16:18:37][Step 1/6] C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1 : A positional parameter cannot be found that accepts argument '$false'.
With colon:
[16:18:37]Step 2/6: Migrate Up (Powershell)
[16:18:37][Step 2/6] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
[16:18:37][Step 2/6] PowerShell arguments: [-NonInteractive, -ExecutionPolicy, ByPass, -File, C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1, "data\change scripts", DB, xxxxxx, sa, *******, -NoExec:$false]
[16:18:37][Step 2/6] C:\BuildAgent\work\f2797fec10821a01\data\Migration\MigrateUp.ps1 : Cannot process argument transformation on parameter 'NoExec'. Cannot convert value "System.String" to type "System.Management.Automation.SwitchParameter". Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.
Removing the [switch] also does not work as any value you give it will not be treated as a Boolean - but rather a string assigned to a Boolean - and, thus, all Boolean operations will be $true.
In other words, anything you send will look like:
0 => '0'
1 => '1'
$false => '$false'
$true => '$true'
(none of which are == $false but all of which are equivalent to $true)
I have no idea how to get TC to accept Booleans!
Best I could do was assume the argument was a string and use System.Convert.ToBoolean() internally in my script...

Answer 2

This is an old question, but if you are still looking for an answer, I managed to get it working.
The main trick is that you shouldn't actually use the colon between the parameter name and the value as you would with PowerShell (I know, confusing...).
It looks like TeamCity is invoking the script in a different way and passes the parameters as string.
So with your example, the following should work:
-preRelease $%IncludePreRelease%
Note that I have added a dollar sign in front of the TeamCity variable to change "true" into "$true"
Let me know if it works for you
Thanks!

Answer 3

According to the Microsoft .Net documentation for Convert.ToBoolean the value passed to the method must be:
For a successful conversion to occur, the value parameter must equal
either Boolean.TrueString, a constant whose value is True,
Boolean.FalseString, a constant whose value is False, or it must be
null. In comparing value with Boolean.TrueString and
Boolean.FalseString, the method ignores case as well as leading and
trailing white space.
If you change your TeamCity IncludePreRelease variable value to either "True" or "False" (without the quotes) then it should convert correctly.

Answer 4

Make passing the switch at all dependent on the configuration parameter:
When you create the Configuration Parameter, choose Type "Checkbox".
In "Checked value", put "-preRelease".
Leave "Unchecked value" blank.
Simply append "%IncludePreRelease%" to your script arguments. When the parameter is checked, it'll pass "-preRelease" (=true), and when it's not, it will be omitted (=false).
This worked for me using TeamCity 10.0.4.

Answer 5

I know this is a late answer but I just had a colleague at work stumble upon the same problem and found this question.
If we forget about TC for a minute, if you wanted to execute the same command from a cmd (not powershell console) the exact command would be:
powershell.exe -File script.ps1 -preRelease
This command sets the switch to True. What is important here is that the command is first parsed by the shell (cmd).
Because the shell is cmd, powershell code in the command line will not be executed.
For example:
powershell -File script.ps1 -preRelase:"([System.Convert]::ToBoolean(%IncludePreRelease%))"
after first pass of the cmd parsing it ends up being:
powershell -File script.ps1 -preRelase:"([System.Convert]::ToBoolean(True))"
so the preRelease flag is being set to the whole string which gives you exactly
Cannot process argument transformation on parameter 'preRelease'.
Cannot convert value "System.String" to type
"System.Management.Automation.SwitchParameter"
Based on the documentation, when using -File you either pass the switch parameters or you don't. There doesn't seem to be a way to pass the True or False value.
To make it work change from -File to -Command like so:
powershell -Command .\script.ps1 -preRelease:$%IncludePreRelease%
Now, back to TeamCity. Teamcity doesn't seem to support -Comand like above. They support it by dumping your whole script into the command line as a script block which can lead to very interesting errors.
The solution is to change the Script to Source and inside the script content add
.\script.ps1 -preRelease:$%env.IncludePreRelease%