Dear PowerShell Santa,

by Klaus Graefensteiner 11. December 2008 01:22

I have been a good boy the past year and I think I deserve some nice presents. And without further ado, here is my Christmas wish list:

Hitachi Powerdrill

Figure 1: Photo of a Hitachi power drill

PowerShell whish list

Professional Tools

Visual Studio Support

I wished PowerShell would be integrated into Visual Studio at least in the same way as for example JavaScript is at the moment. I would like to see rich Intellisense support and integrated debugging. It would be cool to set a breakpoint in the PowerShell script and step all the way down into the Pipeline and the CLR instructions. I would like to get project templates for scripts, cmdlets, providers, hosts, snap-ins and unit tests. On top of that it would be nice to have Visual Studio provide some guidance during the developing of PowerShell scripts that would avoid common mistakes. E.g. using ">" instead of "-gt" or using the wrong scope of variables in scripts. These are very annoying things that can be easily avoided having the right tool. Of course PowerShell is not just another language, it is also "A kind of magic" that should get even in Visual Studio a special kind of treatment. I am thinking for example about a format designer, a type designer and a cmdlet designer that lets you easily generate a script or piece of XML for the PowerShell configuration files.

Thinking about the 2010 version of Visual Studio and the power of WPF in the text editor, wouldn't it be nice to debug a script and see in little windows the script output inline with the script statements that generated them. It would feel like running the script in the CMD shell: Statement -> output, Statement -> output etc.

VS2010 PowerShell

Figure 2: CMD output inline with PowerShell statements in Visual Studio

Other features of the Visual Studio support would be:

  • Auto back ticking
  • Displaying bound parameter names for example as caption when positional parameters are specified
  • De-magic-tizing support in an IDE that takes care of the most commonly and expensive mistakes

I am strong believer in Test Driven Development and Unit test harnesses. It would be very nice to have a Unit testing framework for PowerShell scripts. There are two different approaches. First I could imagine using an existing .NET framework like NUnit and test scripts while using the .NET infrastructure that PowerShell is based on. But this doesn't really feel right. It would be more natural, if the scripts are tested and verified using a framework that is completely designed and implemented around and with PowerShell.

ReSheller and CodeRushell

Refactoring and code generation support would also be very nice. VisualStudio has already ReSharper and CodeRush. PowerShell would benefit a lot from these kind of productivity enhancements.

Language Features

Hash table magic to the power of magic

Hash tables are one of the core data structures of many shell and text processing languages. Unfortunately the way how hash tables are used in PowerShell is in some scenarios completely counter-intuitive and causes me always a lot of grief. Iterating over a hash table should be as auto-magical as iterating over an array. There shouldn't be a need to explicitly call GetEnumerator() or the PSBase property to get the data piped into the pipeline. Another annoyance is the automatic conversion of a hash table into an array or a single instance of  DictionaryEntry objects when piped into a where-object operator. It seems like the magic needs to be re-calibrated in the case of the PowerShell hash table.


Operating Systems

There are cases where PowerShell seems to be an interesting scripting option, but because XP, Vista and Windows 2003 Server don't have the engine installed by default, it is not seriously considered. Wouldn't it nice to include a PowerShell deployment with the delivery of the next Service Pack for each of these operating systems?

PowerShell and Mono

Mono is the open source reference implementation of the .NET CLR at runs on many different platforms. Mono would be a vehicle to do two very cool things: First the PowerShell engine could run for example from a USB memory stick and doesn't need to be installed. The second cool thing is that with Mono there would be a theoretical possibility to execute PowerShell commands on an IPhone. I always wanted to page through the CMD command history by shaking my phone.


I would like to see a PowerShell category in DZone and DotNetKicks. Also a script repository in the cloud would be nice.


PowerShell In Action, Second Edition

The first edition of PowerShell in Action was very good. I hope Bruce Payette is working on a second edition that includes the new features of PowerShell 2.

PowerShell for Programmers

There are a lot of books out there targeted towards the IT audience. I wished the there would be books about how to write applications with PowerShell or integrating PowerShell support into an existing .Net application. Another cool book idea is to write about Domain Specific Languages (DSL) and how to implement them using first PowerShell and then M.


PowerShell has a great potential, but it needs professional tool support in order for it to mature. The current solutions are far too amateur.

Tags: , ,

.NET Framework | PowerShell | Test Automation

Comments are closed

About Klaus Graefensteiner

I like the programming of machines.

Add to Google Reader or Homepage

LinkedIn FacebookTwitter View Klaus Graefensteiner's profile on Technorati
Klaus Graefensteiner

Klaus Graefensteiner
works as Developer In Test and is founder of the PowerShell Unit Testing Framework PSUnit. More...

Open Source Projects

PSUnit is a Unit Testing framwork for PowerShell. It is designed for simplicity and hosted by Codeplex.
BlogShell is The tool for lazy developers who like to automate the composition of blog content during the writing of a blog post. It is hosted by CodePlex.



Powered by:

Creative Commons License

© Copyright 2015, Klaus Graefensteiner.

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Theme design:
This blog theme was designed and is copyrighted 2015 by Klaus Graefensteiner

Page rendered at 5/26/2015 6:31:57 PM (PST Pacific Standard Time UTC DST -7)