PowerShell V2 – backward compatibility

PowerShell Team

Windows PowerShell 2.0 is backward compatible with Windows PowerShell 1.0.

All the scripts written for V1 should work in V2. If you find instances of broken scripts from v1 please let us know through our connect site https://connect.microsoft.com/site/sitehome.aspx?SiteID=99

However there are few points to be noted:


Breaking changes from PowerShell 1.0

·        The value of the PowerShellVersion registry entry in HKLM\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine is changed to 2.0.

·        New cmdlets and variables have been added. These additions might conflict with variables and functions in profiles and scripts.

·        The -IEQ operator performs a case insensitive comparison on characters.

·        The Get-Command cmdlet gets functions by default, in addition to cmdlets.

·         Native commands that generate a user interface cannot be piped to the Out-Host cmdlet.

·        The new Begin, Process, End, and Dynamic Param language keywords might conflict with similar words used in scripts and functions. Interpreting these words as language keywords might result in parsing errors.

·        Cmdlet name resolution has changed. In Windows PowerShell 1.0, a runtime error was generated when two Windows PowerShell snap-ins exported cmdlets with the same name. In Windows PowerShell 2.0, the last cmdlet that is added to the session runs when you type the command name. To run a command that does not run by default, qualify the cmdlet name with the name of the snap-in or module in which it originated.

·        A function name followed by ‘-?’ gets the help topic for the function, if one is included in the function.

·        Parameter resolution for Microsoft .NET Framework methods have changed. In Windows PowerShell 1.0, if you called an overloaded .NET method that has more than one best fit syntax, no error was reported. In Windows PowerShell 2.0, an ambiguity error is reported. In addition, in Windows PowerShell 2.0, the algorithm for choosing the best fit method has been revised significantly to minimize the number of ambiguities.

·        If you are enumerating a collection in the pipeline and you try to modify the collection in the pipeline, Windows PowerShell throws an exception.


For example, the following commands would work in Windows PowerShell 1.0, but would fail after first pipeline iteration in Windows PowerShell 2.0.
$h = @{Name=”Hello”; Value=”Test”}
$h.keys | foreach-object {$h.remove($_)}

To avoid this error, create a sub-expression for the enumerator by using the $() characters. For example:
$($h.keys) | foreach-object {$h.remove($_)}


Restricted verbs and characters: If you use the Import-Module  cmdlet to load commands that use unapproved verbs or restricted characters in the command name, you will receive a warning.

              Use the Get-Verb command to see a list of the approved verbs. Do not use any of the following characters in command names: [ # , ( ) { } [ ] & – / \ $ ^ ; : ” ‘ < > | ? @ ` * ~ % + =


Reserved keywords and parameter names: Windows PowerShell 2.0 has reserved certain keywords as part of language syntax and some names that can be used as parameters to commands.

o   Reserved language keywords: USING, CLASS, DEFINE, and VAR

o   Reserved parameter names: –SelectProperty and –SelectObject 





Osama Sajid , Program Manager


Discussion is closed.

Feedback usabilla icon