Changes in upcoming CTP

Changes in upcoming CTP

  • Comments 5

In my earlier blog, I mentioned that we had changed things since the previous CTP.  Rather than leave everyone wondering whether they were doomed or not, I decided to have an early release of that portion of the release notes.    Here they are:

 

Breaking Changes to Windows PowerShell 1.0

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

2. Added new language keywords: Data, Cmdlet, and DynamicParam. Any commands called data, cmdlet or dynamicParam are interpreted as language keywords and result in parsing errors.

3. Changes in argument separator behavior. In Windows PowerShell 1.0, $a.method(,1) is interpreted as a call with an array of 1 element, but $a.method(1,,2) generates a parsing error. In Windows PowerShell V2, both formats generate parsing errors.

4. New cmdlets and variables have been added. These are listed below. These new elements might conflict with variables and functions in profiles and scripts.

Breaking Changes to Windows PowerShell V2 (CTP)

  1. The attribute declaration for script cmdlets has changed.
    1. Attributes like [Mandatory] or [Position(0)] are now specified as [Parameter(mandatory=$true, position=0)].
    2. Attributes like [ValidateNotNull] now requires parens, like [ValidateNotNull()]
  2. The remoting parameter sets (Runspace, Uri, and ComputerName)have been removed from the Invoke-Expression cmdlet. To run remote commands, use the Invoke-Command cmdlet.
  3. The remoting parameters (Computername, Port, UseSSL, Credential, ShellName, and ThrottleLimit) have been removed from the Start-PsJob cmdlet. To run background jobs remotely, use the AsJob parameter of Invoke-Command.
  4. New-PSBreakPoint has been replaced by Set-PSBreakPoint.
  5. Set-PSBreakPoint is identical to New-PsBreakPoint, except for the following changes.
    1. The Clone parameter is removed.
    2. The Read, Write, and ReadWrite parameters have been replaced by a Mode parameter with values of Read, Write (default), and ReadWrite.
  6. The following automatic variables have been renamed:
    1. $Culture -> $PSCulture
    2. $UICulture -> $PSUICulture
    3. $Cmdlet -> $PSCmdlet

 

Enjoy!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post
  • PingBack from http://blog.sapien.com/index.php/2008/04/24/a-new-powershell-v2-ctp/

  • So let me get this straight.  We have Param as a keyword, and [Parameter()] as an attrib declaration.  That is going to trip people up, don't you think?

    After tossing it around I just don't feel good about the attrib declaration stuff, the syntax is just whack.  I guess Parameter is a function now?

    Question from IRC: "<Jaykul> meaning we can actually do: Parameter(0,1,0,1) if we can figure out the order?"

  • Hey Jeffrey, I think you should like, explain *why* when you do some of these things :P  

    I mean, the Parameter() thing Hal mentioned seems more like the C# syntax, but it also seems more verbose and a little too similar.

    And what's with this Invoke-Command thing -- should it just be called Invoke-Remote?  I mean, other than having all the remoting stuff, does it basically invoke expressions?

  • > I think you should like, explain *why* when you do some of these things

    I totally agree.  That is one of the purposes of this blog - to give you the story behind the story.  Some insight into what we were thinking when we made the decisions we made.  To understand what motivates us so you can predict what we'll do next, what input we are looking for etc.

    BTW - this is why I LOVE Bruce Payette's PowerShell In Action book.  Bruce wrote a book that exactly 1 person in the world could have written.  He explains not just WHAT PowerShell is but WHY it is the way it is.

    We should definately get around to explaining both of those topics but here is the backstory on them.  Both of these were the subject of a TON of discussion, debate, long meetings, coffee discussions etc.  Sometimes that process clarifies the issues and a decisive decision is made that is pithily explained.  Other times, you end up balancing a wide range of competing goals.  

    I'll give you the "oxygen is good" level answer to both these and give  you a raincheck on the longer discussion (We are trying to get the CTP out and I've got a ton of work to do for MMS next week.)

    Parameter[] : This construct aligns with our goal of providing a smooth glidepath between PowerShell and C# and affords us a nice extensible framework for adding easily adding addition semantics.

    Invoke-command:  Our usability studies have videos of people's heads exploding trying to understand Invoke-Expression.  Invoke-Remote was considered but this works in the local runspace as well so that is inappropriate.  It also have rather sophisticated semantics which are difficult to capture in a name but once you understand them, "invoke-command" is a resonable name.  

    Your head is going to spin (one way or the other but hopefully with delight) when you grok what Invoke-Command ACTUALLY does.  I think you'll see that this is a good example of really good design that masks a (necessarily) very complex world.

    Jeffrey Snover [MSFT]

    Windows Management Partner Architect

    Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell

    Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

  • > Our usability studies have videos of people's heads exploding trying to understand Invoke-Expression.

    Can we get a couple of these on YouTube?

    Thanks for the explanations :)

Page 1 of 1 (5 items)