SerialSebTechEd: What's new in PowerShell V2
[EDIT: I'm thrilled by this presentation, can't wait to see the new bits!]
Jeffrey P. Snover [EDIT: Posted on this on his blog]
Before we start talking about v2, lets' talk about v1. The response has been phenomenal. We had a discussion with the Marketing guys. I explained all these things that happened in the past and it'll be a long time before we reach a million download. Was I wrong! We had more than 1.5 Million downloads in the first year.
We have tools shipping today using PowerShell, exchange, MOM, etc. We have more than 20 partners producing powershell inside. We're now a CEC 2009, which means any microsoft server software has to be powershell compatible.
Why the success? You can see the tasks for exchange with VBScript, the productivity for powershell is phenomenal. A customer had a 481 lines of script he replaced with one line thanks to WMI and html formatting.
The bad: Remoting is Cmdlet specific. There's no uniformity you can rely upon. Theres a great scripting language but you can't write Cmdlets in PowerShell. Our scripting environment developement is notepad and ps-debug, which is a pretty lame experience. Finally our API does not address common GUI needs. The normal model is admin tool built on top of powershell. The people doing that end up rewriting the same thing so we are doing it.
The big things for v2 are: Universal code execution model, GUI over PowerShell, Production Scripting, and community feedback.
So what is universal code execution model? Any code that runs should be able to run on one or more machines, LAN or WAN, restricted or not restricted environments, foreground and background, in short or long connections, using impersonation, and initiated by user input or by events.
The code execution model: Invoke-Expression works with computer names, the runspace, the throttle, the credentials, the ShellName, and connection information.
If you want to run it in a backgroun, you can use start-psjob, and the parameters are the same
When we talk about remoting, the scenarios we nail are fan-out 1 to many. The goal is to reduce the TCO. Second is Interactive, and i don't want to use telnet. We're not trying to replace telnet. We're not doing the graphics telnet. Next, Many to 1. If you write a service, you dont want to create a new process for each user, that would blow up. I want to listen on a port with WS-Management. Then we want the GUI over CLI.
Mobile object model. I want to run some code over there, I bring the objects back here but they're exchange objects and we don't have the dll. The way we do that is standardizing the model, we take the type, we serialize in a property bag. It's a stable cross-machine cross-time. Get an object, serialize. It takes one of the 22 types, if it's not there you call ToString. You can specify which serialization you want. Those objects we serialize everytime we reach a RunSpace boundary.
As soon as something crosses, we serialize, and when we reach the destination runspace, we deserialize. We store the original type and we store where it came from. I have a bunch of machines, i do a getFreeDiskSpace and you get the objects back.
[EDIT: Demo of using Invoke-expression].
Background jobs: we had an object called psjob, you can provide a runspace to it, or not. If you don't provide everything we'll run it locally. We require the latest version of WS-Management (1.1), this is included in Vista SP1 but there's no download, so you need SP1. We think the background jobs should be in process, but in this CTP it goes through the remoting.
Jobs can contain child jobs that can contian child jobs.
Restricted Runspaces are environents you can host to run potentially hostile requests safely. You get control of which language features are available, which commands can be executed, and there's white listing of commands.
There's a whole new set of hosting APIs. YOu can only issue one request per run-space. RunSpace pooling, which Exchange did, is a pool of runspaces and execute the job against that pool.
There are a new set of hosting APIs that bypass the parser completely. You can provide parameters, commands, to build a pipeline. There's also a typed invoke, and redo invoke.
[EDIT: Demo of the new hosting API.]
Production scripting: We have a grpahical PowerShell, Script Cmdlets, Script Internationalization/Data Language- You go to the web and solve the problem by downloading a script. It's 3 lines of code. Now imagine it's 3000 lines, it's gonna take a while before you put it into production. Well PowerShell can guarantee it's only data. You look at the lines of code that are not data to evaluate if you run. In scripts you want to highlight which parts of a script you don't need to delve into; Debugging; and finally packages and modules.
Graphical PowerShell is done in WPF it seems.
Script Cmdlets supports most everything a .net Cmdlet can do. You add attribute. You also have the $Cmdlet variable that you get in .net as your base class.
The engine does a ton of work for you. You change from the fucntion name to the Cmdlet. You can add a Mandatory attribute, a Position, an Alias, ValidatePattern etc.
The data language is a limited subset of languages, with comparison operatirs, if / elseif / else, well defined convertfrom cmdlets, limited variables, comments and pipelines, literals.
Data msgs { convertfrom-stringdata 'commands' }
then you import the localized data with Import-LocalizedData msgs.
We have a new command called PSBreakPoint. They can be set on lines, line number / column number, functions, variable read/write, or a breakpoint any time this command is called.By default we hit a breakpoint and break. Alternatively, you can provide an Action scriptblock to execute when you hit the breakpoint. We also have get-PSCallStack. It's a placeholder, but it will be great. In V2 it will be an array of stack information, with location, scope etc.
We're making progress in including community feedback, but we are working on the big bits first.
We now have a splatting operator. We also added a -split and a -join. We added a type for ADSISearcher.