Bespoke Scripting? What Do You Want in PowerShell?

Bespoke Scripting? What Do You Want in PowerShell?

  • Comments 3
  • Likes

Summary: Let the Windows PowerShell team know what you would like to see in the next version.

Microsoft Scripting Guy, Ed Wilson, is here. This week is a complete geek fest for me. I am in Redmond at the Microsoft Corporation headquarters hanging out with the Windows PowerShell team. This morning I had coffee with one of the Windows PowerShell lead developers, Lee Holmes, and then I had lunch with Windows PowerShell PM, Travis Jones. Before all that, I had an early morning meeting with Joshy Joseph who is a principal program manager lead for the way cool Script Explorer. Later I get to meet with distinguished engineer, Jeffrey Snover, who was the lead architect for Windows PowerShell.

Yep. I love my job, but sometimes I REALLY REALLY REALLY love my job—and this week is one of them. But wait, as a late twentieth-century philosopher said, there is more. On Saturday, September 15, 2012, we will have  Windows PowerShell Saturday 002 in Charlotte, NC. There are still a few tickets left, but they really are going fast. Nearly 50 tickets sold over the weekend, so the remaining ones can go very quickly. Register now, before it is too late.

How to impact the next version of Windows PowerShell

Speaking of acting now before it is too late…

When I was talking with Lee Holmes and with Travis Jones, they told me that now is the time to give suggestions for the next version of Windows PowerShell. “But you just shipped Windows PowerShell 3.0,” you might say. Yep, and we immediately begin working on the next version. It is a long road to make a product as cool as Windows PowerShell even better.

This is where the community comes in to play. All Windows PowerShell MVPs basically understand this, but the general Windows PowerShell community might not. I know when I was an IT Pro, I did not get it at first. I would see the Beta of a product come out, and I would say, “I do not have time to mess with that.” Later I would see the Release Candidate come out, and I would say, “I will wait until it releases before I mess with it.” Then I would go to TechEd and complain about this feature not doing what I want it to do, or that feature not doing what I want it to do. It took me just once doing this before I figured out that I should be experimenting with the products I care about as soon as possible.

Right now, the Windows PowerShell team is looking at feature requests that did not make it into Windows PowerShell 3.0. They are also working with other teams and partners to see what features they would like to see in the product. They are busy talking to various customers and to MVPs, and everyone is providing feedback. This is also the time for you to do so. If you wait until the Release Candidate of a product (any product, not just Windows PowerShell), it is pretty much too late to provide meaningful feedback to the product group. They have been working on the product for a long time, and it is nearly feature complete, which means that they have added all the features and functionality they will be able to add. In the Release Candidate stage, the product group is fixing bugs and things like that. There may be time to get some small things into the product, but it will need to meet an extremely high bar to make it in.

During the Beta phase, there is still a bit of time to provide feedback; but even then, most of the features are already baked in. We are looking for bugs that may arise on various machines in different configurations, so we toss a relatively narrow net to capture as many different types of issues as possible.

Recently we have been releasing a Customer Technology Preview. This is pre-beta stuff, and it is designed to see if we are hitting the right balance between new features and improved functionality in the product. Here we are seeking a reality check—are we on target? It is possible that during this phase, new features could still be added to the product.

So all of this is to say NOW is the time to provide feedback to the Windows PowerShell team. They finished Windows PowerShell 3.0. You can download Windows PowerShell 3.0 now for Windows 7, Windows Server 2008 R2, or Windows Server 2008. Windows 8 and Windows Server 2012 have Windows PowerShell 3.0, and they are available via TechNet. Get it, try it out, and if you see something you would like to see in the next version of Windows PowerShell, file a bug on the Microsoft Connect website.

I am not making any promises. There is a good chance that your pet feature will not make it in. I mean, Lee Holmes is a very nice guy, but he did not seem too excited about my ideas for the Windows PowerShell ISE. Travis Jones is way cool, but he did not seem impressed by my idea either. But you know what? They listened. If you log a bug in Connect, someone will read it. They may not answer, but I do know that the bugs are read. And as a matter of a fact, numerous ideas from Connect bugs ended up in Windows PowerShell 3.0. The fact that the Windows PowerShell team listens is one of the major reasons it is such a cool product. Who knows, you might be able to one day demo something and say, “I submitted this as a bug in Connect; and as you can see, the Windows PowerShell team implemented my idea.” I mean, how cool is that?

Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • A few things I would like to see in a vNext:

    1) Default capabilities to create things ISO images and other "compressed" binary formats commonly used in software/application storage.

    2) the ability to create and manage zipped packages (with various formats and encryption formats).

    3) integration with application packaging such as MSBuild, WIX and MSI deployment. In other words, cmdlets, not just Win32 application calls to regular applications.

    4) IDE/ISE support for Visual Studio so I can use TFS without feeling like an intruder in my own development efforts (hey, I figure why not ask since the table's open).

    5) Non-Windows ports (i.e., Linux) of PowerShell. I know there is talk....

    Wishing from the front lines.

  • @Will Steele these are some great recommendations. Could you add them as Connect bugs for the PowerShell team?

  • Thank you for your article post.Much thanks again. Really Cool.