locked
PowerShell Difference between Set-StrictMode V2,V3,V4. RRS feed

  • Question

  • Could somebody please explain the difference between setting Set-Strictmode -Version 2, -Version 3, and -Version 4, as opposed to just using -Latest?
    Monday, December 16, 2013 8:01 AM

Answers

  • The easiest way to explain exactly what I am trying to do is to go to Repository here and check Get-StrictMode.psm1, which is intended to do the same as the above example, but in a far simpler way.

    I actually checked your script before I posted my reply. Reading the value of StrictModeVersion directly rather than relying on code that violates a certain StrictMode version represents for me actually a simpler and more scalable solution. There is no need to update this one, every time there is a new PowerShell version.
    • Marked as answer by Trader_Horn Wednesday, December 18, 2013 6:09 AM
    Wednesday, December 18, 2013 2:29 AM

All replies

  • It might be stating the obvious but Latest will make use of the latest version installed on the computer. For example if you've only got v2 installed on your local machine (A) then -Version 2 and -Latest are identical in result.

    On the other hand if the local machine (B) has version 4 installed and you use the -Latest flag it will compile in version 4 mode instead. This means that running the same script on computers A and B may result in different behaviour.

    The short version is that if you want to make sure you know what your script will do you should name your version, but just using the -Latest flag is still going to get you 80%+ of the security that a named version will.

    Monday, December 16, 2013 9:09 AM
  • Well - almost

    There are only three modes 1, 2 and latest.

    help set-strictmode -full

    Each one enforces a different level of checking for "strict" compliance.  -latest will enforce at the level of the latest available version on the machine you are running it on.

    This command is only valid on Versions 3 and later.

    Strict-Mode is mostly for developers of CmdLets and Modules.  This helps with large code sets but is not recommended if you are not a well experienced scripter or for very small projects.


    ¯\_(ツ)_/¯


    • Edited by jrv Monday, December 16, 2013 1:33 PM
    • Proposed as answer by Alex Brassington Monday, December 16, 2013 3:11 PM
    Monday, December 16, 2013 1:31 PM
  • Thank you both for that. The problem is, in the absence of a Get-Strictmode cmdlet, I need to know an exact command that will trigger an error for each level. A while ago I submitted such a script to the repository here and I need to update it, as it only checks V1 and V2.
    Monday, December 16, 2013 11:56 PM
  • I think you are really looking for this:

    #requires -Version 2.0

    This guarantees that the user will be notified if they try to run it on version 1. 

    Set-Strict is not for the end user.  It is for the developer.  As I posted above.  If you are not a wel experienced developer you should not be using strict.

    As long as you have to ask about it you should not use it.  Eventually you will likely learn enough about scripting and programming large projects to understand how to use "strict".

    You have posted nothing that indicates that it is required for anything you are doing.  Use "#requires" instead.


    ¯\_(ツ)_/¯

    Tuesday, December 17, 2013 12:00 AM
  • Thank you both for that. The problem is, in the absence of a Get-Strictmode cmdlet, I need to know an exact command that will trigger an error for each level. A while ago I submitted such a script to the repository here and I need to update it, as it only checks V1 and V2.

    You can read the value via Context.EngineSessionState.CurrentScope.StrictModeVersion. Have a look into the implementation of the Get-StrictMode posted here:

    http://powershell.cz/2013/02/25/get-strictmode/


    • Edited by Dirk_74 Tuesday, December 17, 2013 10:12 AM
    Tuesday, December 17, 2013 10:12 AM
  • The easiest way to explain exactly what I am trying to do is to go to Repository here and check Get-StrictMode.psm1, which is intended to do the same as the above example, but in a far simpler way.
    Wednesday, December 18, 2013 12:13 AM
  • The easiest way to explain exactly what I am trying to do is to go to Repository here and check Get-StrictMode.psm1, which is intended to do the same as the above example, but in a far simpler way.

    You have to explain why you think you need to set strict mode on.  It I snot useful for normal admin scripts.  It is used for developers working on very large projects.


    ¯\_(ツ)_/¯

    Wednesday, December 18, 2013 12:34 AM
  • The easiest way to explain exactly what I am trying to do is to go to Repository here and check Get-StrictMode.psm1, which is intended to do the same as the above example, but in a far simpler way.

    I actually checked your script before I posted my reply. Reading the value of StrictModeVersion directly rather than relying on code that violates a certain StrictMode version represents for me actually a simpler and more scalable solution. There is no need to update this one, every time there is a new PowerShell version.
    • Marked as answer by Trader_Horn Wednesday, December 18, 2013 6:09 AM
    Wednesday, December 18, 2013 2:29 AM
  • I took the link that Dirk found and made my own version of the function. It gets the current scope's StrictMode, not just the global scope's. You can find it here.
    • Edited by Rohn Edwards Wednesday, December 18, 2013 11:35 PM
    Wednesday, December 18, 2013 11:35 PM
  • Hi Rohn,

    nicely done, thanks a lot for sharing. I also wanted to revisit this function to understand how this is done (Get-Field), since it gives you access to many interesting properties that are otherwise hidden under the hood. It would have taken me ages to figure it out, so thanks again for your work.

    Thursday, December 19, 2013 1:59 AM