Powershell: Import-Module cmdlet doesn't respect -Verbose:$false switch

[splatteredbits]

You can't turn off verbose output when importing modules by setting the -Verbose switch's value to $false.

Steps to reproduce

$VerbosePreference = 'Continue'
Import-Module -Name 'PSDesiredStateConfiguration' -Verbose:$false -Force

Expected behavior

I would expect there to be no verbose output when importing the module.

Actual behavior

I see verbose output:

VERBOSE: Exporting function 'Configuration'.
VERBOSE: Exporting function 'New-DSCCheckSum'.
VERBOSE: Exporting function 'Get-DscResource'.
VERBOSE: Exporting function 'ConvertTo-MOFInstance'.
VERBOSE: Exporting function 'Get-MofInstanceText'.
VERBOSE: Exporting function 'Get-PositionInfo'.
VERBOSE: Exporting function 'Node'.
VERBOSE: Exporting function 'Update-ConfigurationErrorCount'.
VERBOSE: Exporting function 'Get-ConfigurationErrorCount'.
VERBOSE: Exporting function 'Set-PSDefaultConfigurationDocument'.
VERBOSE: Exporting function 'Get-PSDefaultConfigurationDocument'.
VERBOSE: Exporting function 'Get-PSCurrentConfigurationNode'.
VERBOSE: Exporting function 'Set-PSCurrentConfigurationNode'.
VERBOSE: Exporting function 'Set-NodeResources'.
VERBOSE: Exporting function 'Test-NodeResources'.
VERBOSE: Exporting function 'Add-NodeKeys'.
VERBOSE: Exporting function 'Get-InnerMostErrorRecord'.
VERBOSE: Exporting function 'Initialize-ConfigurationRuntimeState'.
VERBOSE: Exporting function 'ValidateUpdate-ConfigurationData'.
VERBOSE: Exporting function 'Test-ModuleReloadRequired'.
VERBOSE: Exporting function 'Configuration'.
VERBOSE: Exporting function 'ImportCimAndScriptKeywordsFromModule'.
VERBOSE: Exporting function 'Write-NodeMOFFile'.
VERBOSE: Exporting function 'ValidateNodeResources'.
VERBOSE: Exporting function 'ValidateNoCircleInNodeResources'.
VERBOSE: Exporting function 'StrongConnect'.
VERBOSE: Exporting function 'Test-MofInstanceText'.
VERBOSE: Exporting function 'Get-EncryptedPassword'.
VERBOSE: Exporting function 'Get-PublicKeyFromStore'.
VERBOSE: Exporting function 'Get-PublicKeyFromFile'.
VERBOSE: Exporting function 'New-DSCCheckSum'.
VERBOSE: Exporting function 'ThrowError'.
VERBOSE: Exporting function 'Write-Log'.
VERBOSE: Exporting function 'WriteFile'.
VERBOSE: Exporting function 'ReadEnvironmentFile'.
VERBOSE: Exporting function 'Get-DscResource'.
VERBOSE: Exporting function 'GetResourceFromKeyword'.
VERBOSE: Exporting function 'GetCompositeResource'.
VERBOSE: Exporting function 'AddDscResourceProperty'.
VERBOSE: Exporting function 'AddDscResourcePropertyFromMetadata'.
VERBOSE: Exporting function 'GetSyntax'.
VERBOSE: Exporting function 'CheckResourceFound'.
VERBOSE: Exporting function 'GetImplementingModulePath'.
VERBOSE: Exporting function 'GetModule'.
VERBOSE: Exporting function 'IsHiddenResource'.
VERBOSE: Exporting function 'GetPatterns'.
VERBOSE: Exporting function 'IsPatternMatched'.
VERBOSE: Exporting alias 'sacfg'.
VERBOSE: Exporting alias 'tcfg'.
VERBOSE: Exporting alias 'gcfg'.
VERBOSE: Exporting alias 'rtcfg'.
VERBOSE: Exporting alias 'glcm'.
VERBOSE: Exporting alias 'slcm'.
VERBOSE: Exporting function 'Get-DscConfiguration'.
VERBOSE: Exporting function 'Test-DscConfiguration'.
VERBOSE: Exporting function 'Get-DscLocalConfigurationManager'.
VERBOSE: Exporting function 'Restore-DscConfiguration'.

Environment data

> $PSVersionTable

Name                           Value               
----                           -----               
PSVersion                      4.0                 
WSManStackVersion              3.0                 
SerializationVersion           1.1.0.1             
CLRVersion                     4.0.30319.42000     
BuildVersion                   6.3.9600.16406      
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2                 

[mklement0]

It looks like this is a problem in existing _production_ versions, but not in PowerShell Core as of v6-beta.3 (the current release here), so you should probably report this at uservoice.com.

[mklement0]

@iSazonov, @SteveL-MSFT:

Can you please clarify the exact policy for when issues should be reported _here_, as opposed to at uservoice.com?

My understanding is:

• If the issue is _not_ (no longer) present in the _this repository's master branch_ (loosely speaking: in the current _Core_ release), it should be reported at uservoice.com rather than here.

  • If it _is_ present here, it is hopefully _enough_ to report it _just_ here, and not _also_ at uservoice.com, correct?

• In other words: issues that _only_ affect _officially released production versions_ should be reported at uservoice.com.

Can you confirm this understanding?

We should update https://github.com/PowerShell/PowerShell/blob/master/.github/ISSUE_TEMPLATE.md
accordingly (I'm happy to do that, once I have clarity).

[mklement0]

Tangent alert (may be of interest to some; I'm sharing it, because it baffled me initially):

The processing of -Verbose:$false is somewhat unusual in this case:

Unless you take extra action, passing -SomeSwitch:$false and _omitting_ -SomeSwitch are equivalent.
The $SomeSwitch parameter variable will be a [switch]-typed variable whose .IsPresent property (a somewhat unfortunate choice of property name) is $False in _both_ cases.
From what I understand, that is the intent behind -SomeSwitch:$false, which normally only exists to facilitate _programmatic_ construction of a command line.

The only way to distinguish these two cases is to do something like $PSBoundParameters.ContainsKey('SomeSwitch') (or its C# equivalent in a compiled cmdlet), which is apparently what happens here (in PowerShell _Core_, where this issue's problem does _not_ happen any longer): $PSBoundParameters.ContainsKey('SomeSwitch') returning $True despite $SomeSwitch.IsPresent returning $False implies that -SomeSwitch:$False was passed.

Thus, -Verbose:$false functioning as a signal to _override_ the $VerbosePreference variable (as opposed to having _no effect_, which is what seemingly happens in the current production versions) is a semantic anomaly, but it is helpful and documented.

[SteveL-MSFT]

@mklement0 This repo is specifically for PSCore6 so issues that don't repro with latest version of PSCore6 should not be reported here. Windows PowerShell issues should be reported on UserVoice and are handled differently. If the issue repros on both, I would say in general report on both. However, if it's not a blocking issue, I would recommend just reporting it here with the expectation we would only fix it in PSCore6.

I believe @joeyaiello is working on a blog post to clarify some of this.

[mklement0]

@SteveL-MSFT: That's helpful, thanks - quick follow-up: Going forward (v6+), will _Windows PowerShell_ be built directly from _this_ repo as well?

[iSazonov]

I must add that there are PowerShell modules from other product groups. Reports on them are better sent by Windows 10 Preview Feedback tool.

[iSazonov]

@mklement0 Future is that PowerShell Core will replace Windows PowerShell. I believe Microsoft retains standard support lifecycle for Windows PowerShell will only develop the Core version.

[SteveL-MSFT]

@mklement0 Windows PowerShell 5.1 in Win10 is not built from this repo. This repo is effectively a fork from the closed source that is in Windows. When there are changes that meet the servicing bar for Windows PowerShell 5.1, the workflow my team follows is to make the change in PSCore6 first, then we port it to the Windows code base. To clarify a statement by @iSazonov, there are no plans to replace Windows PowerShell 5.1 with PowerShell Core 6.0 inbox. Windows PowerShell 5.1 will be the inbox version of PowerShell on Windows for the indefinite future which we will continue to support. Once PowerShell Core 6 gets to GA and we get all the Windows partner teams to ensure compatibility with their modules, then we'll decide the relationship of Windows and PSCore6 (putting stuff in Windows isn't as simple as just doing an xcopy...)

[MaximoTrinidad]

Guys! I've seen many times Windows PowerShell issues been presented in GitHub. Is there a way that in the main page this is properly explained?

This will clear any confusion about Windows PowerShell vs PowerShell Core. Also, providing the appropriate links to Windows PowerShell Uservoice.

This will definitely help!!

:)

[SteveL-MSFT]

@MaximoTrinidad excellent point, I'll update the readme

[mklement0]

@SteveL-MSFT: Thank you for that important clarification and for planning to post it more prominently.