Enable-NetFirewallRule doesn't respect -WhatIf when called from advanced function #6556

Activity

1. PetSerAl commented on Apr 4, 2018

   

   PetSerAl

   on Apr 4, 2018

   Last edited by PetSerAl

   Contributor

   More actions

   $WhatIfPreference variable do not cross module boundaries:

   New-Module {
       Set-StrictMode -Version Latest
       function f {
           [CmdletBinding(SupportsShouldProcess)]param()
           $WhatIfPreference # True
           $global:WhatIfPreference # False
           $local:WhatIfPreference # True
           g
       }
   } | Out-Null
   New-Module {
       Set-StrictMode -Version Latest
       function g {
           [CmdletBinding()]param()
           $WhatIfPreference # False
           $global:WhatIfPreference # False
           $local:WhatIfPreference # Error
       }
   } | Out-Null
   $WhatIfPreference # False
   f -WhatIf

   👍React with 👍1Reacted by Michael Klement
2. mklement0 commented on Apr 4, 2018

   

   Michael Klement (mklement0)

   on Apr 4, 2018

   Last edited by mklement0

   Contributor

   More actions

   To complement PetSerAl's helpful example with additional information:

   Enable-NetFirewallRule is defined in a module and implemented as a (PowerShell) function rather than as a compiled cmdlet.

   Unfortunately, as PetSerAl's example shows, functions imported from modules do not see (implicitly set) preference variables from the callers's scope (unless that scope happens to be the global one).

   In the case at hand, your TestEnableNetFirewallRule function's [CmdLetBinding(SupportsShouldProcess)] attribute causes PowerShell to translate the -WhatIf switch into a local $WhatIfPreference variable with (effective) value $True (it is technically a [switch] instance whose .IsPresent property reports $True and therefore acts like $True in a Boolean context).

   However, due to Enable-NetFirewallRule living in a (different) module, it doesn't see TestEnableNetFirewallRule's local $WhatIfPreference value and therefore doesn't honor the original -WhatIf switch.

   This problematic behavior is the subject of #4568.
3. juliank commented on Apr 4, 2018

   

   Julian Klock (juliank)

   on Apr 4, 2018

   Author

   More actions

   Thank you for the in-depth explanation Michael Klement (@mklement0). My knowledge of PowerShell is rather limited, and this difference in behavior between functions and compiled cmdlets was totally unknown to me (I guess I was just lucky when I posted #6342 a month ago, that it was an actual bug and not just a function/cmdlet issue).

   From what I can read from #4568 which you mention, there doesn't seem to be any easy and straight-forward way of telling whether -WhatIf will behave as "expected" or not. So I guess the only thing I can do is to assume that it never will, and always test it? In any case it's an interesting discussion going on in the referenced issue thread.
4. mklement0 commented on Apr 4, 2018

   

   Michael Klement (mklement0)

   on Apr 4, 2018

   Last edited by mklement0

   Contributor

   More actions

   Julian Klock (@juliank): Thanks for the follow-up:

   #6342 is indeed a manifestation of the same problem after all, as I've only just now realized.

   If you do agree that #4568 is a problem, I encourage you to give it a thumbs-up - surprisingly few people have, so far.

   So I guess the only thing I can do is to assume that it never will, and always test it?

   Yes - unfortunately; to spell out the cumbersome workaround, using splatting:

   function TestEnableNetFirewallRule() {
       [CmdLetBinding(SupportsShouldProcess=$true)]
       param ([string]$DisplayGroup)
   
       $htWhatIfPassThru = @{ WhatIf = $WhatIfPreference }
   
       Enable-NetFirewallRule -DisplayGroup $DisplayGroup @htWhatIfPassThru
    }
   

   Note that the above just covers -WhatIf; to cover all common parameters, you'd have to apply the same logic to all of them.
5. juliank commented on Apr 4, 2018

   

   Julian Klock (juliank)

   on Apr 4, 2018

   Author

   More actions

   Thank you for the suggested workaround Michael Klement (@mklement0). Splatting was new to me, so I would have gone for the even more cumbersome workaround surrounding my call to Enable-NetFirewallRule using if (ShouldProcess(..., "...")). And if I read it correctly, it is easily adjustable to also account for -Confirm, which will cover my scenarios in this case.
6. mklement0 commented on Apr 4, 2018

   

   Michael Klement (mklement0)

   on Apr 4, 2018

   Contributor

   More actions

   Julian Klock (@juliank): Yes, it should work analogously for -Confirm / $ConfirmPreference.

   👍React with 👍1Reacted by Julian Klock
7. Ilya (iSazonov)

   added

   Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a

   on Apr 6, 2018
8. Ilya (iSazonov)

   added

   Resolution-AnsweredThe question is answered.The question is answered.

   on Sep 28, 2019
10. ghost closed this as completedon Sep 30, 2019