PowerShell 6Beta2 still has the same gotcha as Windows PowerShell that one needs to manually pass and set the VerbosePreference into scriptblocks, even when using advanced functions. It would be nice if the VerbosePreference of the Invoke-Command Cmdlet would be set automatically in the executed scriptblock.
Invoke-Command -ScriptBlock {Write-Verbose "Hello World"} -Verbose
Invoke-Command -ScriptBlock {[CmdletBinding()]Param() Write-Verbose "Hello World"} -Verbose
I would expect in both cases that the VerbosePreference gets applied automatically
VERBOSE: Hello World
No verbose output.
One has to pass and set it manually to get it working:
Invoke-Command -ScriptBlock {[CmdletBinding()]Param($VerbosePreference) Write-Verbose "Hello World"} -Verbose -ArgumentList ('Continue')
Name Value
---- -----
PSVersion 6.0.0-beta
PSEdition Core
BuildVersion 3.0.0.0
CLRVersion
GitCommitId v6.0.0-beta.2
OS Microsoft Windows 10.0.15063
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
@bergmeister I see the ask here, but how would you specify that you want -Verbose on the Invoke-Command, and not on the -ScriptBlock? You'd still have to provide a way to do that.
@pcgeek86 My impression was that with the general usage of -Verbose is that one either gets no verbose output or everything. For example consider when calling function A that calls function B internally, the VerbosePreference propagates from A to B by default without doing anything. That's why I thought that this would be the more common and intuitive default and in the special case if one really wanted the Verbose output from Invoke-Command only but not the ScriptBlock one could still pass the desired VerbosePreference to the ScriptBlock as Invoke-Command -ScriptBlock {[CmdletBinding()]Param($VerbosePreference) Write-Verbose "Hello World"} -Verbose -ArgumentList ('SilentlyContinue')
This is certainly a more philosophical discussion but to me it would make the behaviour more consistent and intuitive. Should the outcome of this discussion be a change, then one would most certainly also need to include other preferences such as InformationPreference (and maybe even the WhatIfPreference).
I too ran into the same problem with not understanding why my verbose statements within an Invoke-Command were not outputting. It is confusing and adds extra work.
If you think about it, the expectation with Invoke-Command is to execute all statements within the script block remotely. Output is already routing back to the local terminal session to be displayed. So when you see Write-Verbose statements, and -Verbose set on the Cmdlet, you expect it to show up.
As for the conflict with Invoke-Command having it's own Verbose statements, as far as I can tell, there are none. If there were, it wouldn't be an issue with -Debug or -Verbose showing the connection activities mixed in with my Verbose. It could actually help if something were broken in remoting.
I think having verbose output for both the Invoke-Command cmdlet and the command itself is sane default behaviour. If someone wants verbosity only from Invoke-Command itself and not the command, they can set $VerbosePreference or pass the -Verbose:$false switch to the commands explicitly in the command scope or by using a similar workaround explained above.
I have to support this idea as well: Invoke-Command should definitely pass it's own -Verbose parameter to the script it's executing. I've tried every workaround and they all suck. Can't see this breaking anything.
+1
This seems more like a bug than a feature. Users expect the CmdletBinding properties to propogate through an Invoike-Command - any chance they will in the near future?
Here is a related RFC.
Most helpful comment
Here is a related RFC.