“Captain Literal”.NET

I’ve been using PowerShell now for a few months and it’s become a standard feature on my desktop. Having used it for a while I have some observations to share:

IDE

PowerShell doesn’t have an IDE shipped as part of the product, so the out-of-the-box experience of scripting it limited to nothing more fancy than Notepad. My experience though has been that an IDE of some sorts really is required for working with anything but the most basic .ps1 script files. Additionally, I’ve had bugs in one-liners that pipe together several command and full IDE support for pipelines would be a real winner – imagine being able to set a breakpoint between piped commands.

The main features that I would like an IDE for PowerShell to provide are:

• Colourisation of text – Different types and operators get different colours when viewed in an IDE, so you can see what you’re working on more clearly.
• Full Debugging capabilities – Including breakpoints and watch windows. Without these basic tools, scripts get littered with write-Debug commands all over the place, it kind of reminds me of days gone by when I’ve been debugging ASP3 web applications – doable, but not as easy as it should be.
• IntelliSense – tab completion is a godsend, but you need to know what’s there before it really works, I’m constantly piping to get-member to find out what an object supports.
• Code-snippets – I know this is a very Visual studio term, but in essence I’m talking about templated commands rather than scripts. For example, a simple getNamedProcesses snippet could contain: Get-Process [ProcessName], where the user just overwrites the [ProcessName] block with the desired information and away it runs. Again, linked with a visual menu so one can browse code-snippets would be the ultimate.
  This could be a very powerful tool for PowerShell as it provides another way to reuse functionally.
• Source code Control – Creating a corporate or personal script library will take time and require multiple scripter’s/developers working on the same solution. This is a situation that cries out for source code control and solution management and not just a bunch of files on a share somewhere.

I know there are a few IDE’s for PowerShell already and over the next couple of week I intend to install them all to see how they are, but what I’d really like is Visual studio to understand PowerShell, or at least .ps1 files. I use Visual Studio every day so I’m very comfortable in it, but I understand that the vast majority of PowerShell users are going to be IT Pro’s who do not have Visual Studio at hand – but that’s no reason not to use it for this purpose. Of cause, a lighter-weight version would be required for the non-development activities that occur on production servers inside the data-centre – I really would not like to be the one who says “Install VS on all those servers please.”

Right Tool, Right Job

PowerShell is a new tool for the toolbox, but unlike other tools it isn’t another item to carry around and only get out when required. PowerShell is much more like a multi-function screwdriver – the ones with a billion different mutli-changeable bits to achieve anything (bad simile I know and not to be taken literally). It’s a tool that does away with several others and like all multi-purpose tools has some drawbacks and isn’t suited for every job. Fortunately, it interfaces with tools that can be used like .NET or native .exe’s.

One area where I found PowerShell suffers is for performance. Normally performance is not necessarily at the top of the features list – especially when we’re talking about admin scripting, which is what PowerShell is designed for. But sometimes you want a script to run as quickly as possible, you need a script to run as quickly as possible. Take the Sudoku solving script I posted a couple of weeks ago, I wanted to make it perform. True, I did not take advantage of any unique-to-shell-features (such as Pipelines) and as a result those features (which are normally what I use PowerShell for) added an overhead. The correct tool for that job was .NET itself, invoked through PowerShell of cause.

Maybe it’ll get optimised in a future version and my only purpose for listing it here is to try and make people aware of the choices that are available and to know the pros/cons of each so the best tool can be chosen for the particular job at hand. I really don’t see performance as a problem for this tool, so don’t worry too much about it – it’s quick enough for 99.999% of the things I do in it.

Because I can create .NET classes or call static methods at the command line and interact with them, I will be able to throw functionality into .NET classes and have .DLL’s as part of my personal script library without having the overhead and formality of writing an entire cmdlet/snapin.

Operators

PowerShell has good support for a wide array of operators, but it doesn’t support all that are provided to other .NET languages like C#. Examples are %= (modulus assignment), << (left-shift),
>> (right-shift) and ?: (conditional). Jeffrey Snover has blogged about ?: on the PowerShell Team blog.

This isn’t a big problem as you can wrap these operators up in managed code and invoke them as statics if required – perhaps the first class I should add to my .dll-enhanced script library?

I hope that future releases of PowerShell will provide additional operator support, but right now, the main operators (the ones used daily) are supported.

Remote Machine Support

One of the IT Pro’s where I work, who is very pro-scripting has commented that PowerShell’s lack of remote machine working ability is a problem for him. This is a fair comment, PowerShell is set-up for local working and very little support is provided for remote connectivity and management of computers. I say very little because PowerShell has great support for WMI, ADSI and .NET – so you can do all this, it’s just not a simple as the following examples:

get-process –machineName server.domain.local

stop-service –name serviceName –machineName server.domain.local

The IT Pro mentioned above isn’t a developer and I think that WMI and .NET are not the simplest things to pickup and learn – they both have massive object models – so I think that the community is going to come out with these sorts of tools more.

To mitigate this, I know that PowerShell Remoting addresses this issue by providing a service on a remote machine that allowing a client to connect – like telnet – and even goes one further by providing extra cmdlets that you can use to get the information over the network to the client computer. It’s nicely thought out and it’s another one that I’m going to add to my //ToInvistigateFurther: list.

Looking ahead to Longhorn Server, administrators will be able to expose PowerShell as a remote application – imagine a Remote Desktop Session, but for only one application instead of the entire desktop. I’m not sure I like this approach though, I want tools that don’t encourage administrators to use mstsc and don’t require them to start a desktop session on a server.

Finally, I don’t mind this as I believe that all changes to servers in data centres should be run through a central controller so the command, output and executing user can all be logged and queried later – how else are you going to know what happened on any given machine? I’m a big fan of Automated Deployment Services (ADS) and this is the administration model it promotes. As an aside, you can run PowerShell commands and scripts from ADS by calling powershell.exe as the command and –command “command list” as a parameter. For example:

powershell.exe –command “& { gps }”

powershell.exe –command “& { C:\PsScripts\dosomething.ps1 }”

Type powershell -? for more details from the command line.

Documentation

I like the way that the get-command and get-help cmdlets are used to get help, but it’s not always easy to find the help topic I’m interested in – Example: param – can’t find any help on it using get-help, I had to resort to Windows Search to find the xml file it’s in – perhaps a simple search-help cmdlet might work? Again, I think that the community will provide this over time.

Whilst on the subject of documentation, one thing that really bugs me with the x64 release of PowerShell on a machine with Office installed is that clicking on any of the start menu documentation shortcuts results in Word not being able to find the requested document because it’s a 32bit process and PowerShell only installed the .rft files to the 64bit version of System32. Still, you can open them in WordPad or just copy them to the correct place in the SysWow64 folder.

To Finish

Phew, what a lot to type and I’m sure that I’m going to have forgotten loads that will come to me over time, so I may end up doing another one of these posts in the future.

I hope that this doesn’t read like a rant, because I didn’t intend it to be one. If you haven’t gathered already, I really like PowerShell and think that it has massive potential. Given time, I’m sure that we’ll see more and more support for it in other application – perhaps Microsoft will add it to their Common Engineering Criteria for server based applications?

I mention the community a lot in the above essay and I am part of that community. Right now, I’m working on some network tools for PowerShell that should make life a little easier.

Edit: Thanks to /\/\o\/\/ for point out that I missed that PowerShell does actually have the modulus assignment operator (%=) - missed that one, D’Oh!

Filed under: PowerShell