Download Links for PowerGUI and QAD cmdlets

powergui logoWith Dell’s acquisition of Quest and all the IT reorganization that followed, it is actually not that easy to find these two popular free PowerShell tools any longer. So here are the links that work today (January 30, 2015):


The download is freely available from Dell’s PowerGUI community.

The community itself also got moved from http://powergui.org to http://en.community.dell.com/techcenter/powergui.

Dell Software is still maintaining the product – as I am writing this the latest version is 3.8 released in April 2014.

Quest / QAD cmdlets

This one is a little more tricky to find: https://software.dell.com/register/71110

If this link for some reason changes, all Dell’s freeware and trial links can be found in this catalog: http://software.dell.com/trials/

Happy PowerShelling!

Categories: Powershell

A better approach to formatting in PowerShell

Even without a traditional user interface, it is important to separate the presentation layer from the data processing layer.

For all of its strengths, Windows PowerShell is not without its fair share of weaknesses.  One of the weaknesses in PowerShell that has been with the scripting language since version 1.0 is how it handles formatting.  When it comes to formatting data, you have two options: use one of the core Format-* cmdlets (Format-Table, Format-List, Format-Wide, or Format-Custom), or create a format ps1xml file that defines one or more formats for a specific type in an XML document.  The former only works for the script consumer, because the core Format-* cmdlets actually convert rich object data into format data, not bearing any resemblance to the original objects with properties and methods that you started with.  The latter works for the script author as well as the script consumer, however it is significantly more complicated to implement, and it has its share of limitations as well (for example, once a default format is defined for a type, a script author will not be able to have the results of their script rendered in another format by default without taking some extra steps that shouldn’t be necessary).  The end result of these limitations and complications is a formatting system that is not fully leveraged in the majority of PowerShell scripts that are shared among the community.

I recently found myself looking at this problem and asking myself one more time if I could do better (it is a problem that I had looked at in the past).  The variety of formats that are available is encouraging, and you can generate some pretty useful report-like output when you take the time to leverage the formatting system.  But something would have to be done to fix the user experience.  The end goal I was envisioning was quite clear: a distinct separation of the presentation layer from the data processing layer such that formatting information would never get in the way of data processing.

Fortunately, PowerShell is quite well set up for this type of change.  Every command that you run has its results sent through the Out-Default cmdlet.  Out-Default internally knows what to do with whatever you throw at it, whether that be object data or format data (which really is object data as well, but I’m making a distinction here).  When you return an object from a command to the console, if that object is not format data, Out-Default internally will look at the object type, identify the default format for that type, convert the object into format data and then output that format data to the console.  If Out-Default does receive format data instead because the object was already converted into format data, it simply renders that format data in the console.  Given that is the case, it should be possible to modify the core Format-* cmdlets so that they attach format data to the objects that they format instead of converting object data into format data, and it should also be possible to modify the core Out-Default cmdlet so that it detects format data when it is attached to an object and renders that format data directly to the console instead of looking at the object type to decide what format to use.  That, my friends, is exactly what I did.

FormatPx is a module made up of a nested binary module that defines five proxy cmdlets (Format-Table, Format-List, Format-Wide, Format-Custom, and Out-Default) plus one new cmdlet (Format-Default) and a script module that automatically applies the Force parameter whenever Format-Table, Format-List, or Format-Wide are used.  It changes how the core Format-* cmdlets work as described above, and it also makes it easier to get format information from types that include a custom format as their default.  Here’s a short screencast showing FormatPx in action:

(Note, do not adjust your computer, there is no audio in this screencast.)

Better PowerShell formatting with FormatPx

That’s a decent overview of what you get with the FormatPx module – a separation of the formatting layer from the data processing layer, giving you much more control over the presentation of your script results without ps1xml file complexity while still allowing script consumers to view the results in whatever format they like.  What do you think?

Kirk out.

Categories: Powershell

PowerShell Tools for Visual Studio – Now 100% more free!

Adam Driscoll's Blog - Mon, 18-Aug-14 19:28

Recently, the Python Tools for Visual Studio team released support for Visual Studio Express 2013. After emailing the team, I found that there is a white list of extensions that are allowed to be installed in Express. Unfortunately, this is an internal Microsoft process and not available to external developers. Although this was a bummer, they pointed me once again towards the Visual Studio Isolated and Integrated Shell. I had previously experimented with the Isolated Shell with little luck and didn’t pursue it until a nudge from the PyTools team. Rather than having to create an entire Isolated Shell environment, you can instead download and install the Integrated Shell. It provides the entry point to launch the components provided by the Isolated Shell. It certainly was confusing to me but I gave it a shot. Success! You can download and install both the Isolated and Integrated Shells and then install PowerShell Tools for Visual Studio. 100% free!

Installation Steps

1. Download and Install the Isolated Shell
2. Download and Install the Integrated Shell
3. Open Extensions and Updates…
4. Install PowerShell Tools for Visual Studio

Black magic:


So far, it looks like there are a couple features that aren’t working quite correctly.

- Debugging doesn’t seem to work as expected. This really limits the functionality and I’ll be looking into it.
- No built in source control integration. This sucks but is just a limitation of Isolated Shell. There are extensions for Git and SVN available on the gallery.

Otherwise, things stuff as IntelliSense, REPL, Syntax Highlighting and the project system seem to be behaving.

Feel free to try it out and look forward to updates in the near future.

Categories: Powershell

PowerShell Tools – v0.8.0 – Now with REPL!

Adam Driscoll's Blog - Sun, 15-Jun-14 16:19

Today, I’m announcing the release of PowerShell Tools for Visual Studio v0.8.0. There are some important installation changes in this version and I want to make sure people are aware. You can download the latest on the Gallery (2012\2013) or via GitHub.

Installation Changes – Important!

The extension has been broken into two different editions based on Visual Studio version. This was done to fix installation issues caused by how the extension was being built. Building a different version for each version of Visual Studio has corrected this. For Visual Studio 2012 users, you’ll need to uninstall your current version of the extension and install the new version. Installing them side by side will cause issues. This should be the only time you’ll have to do something like this.

REPL Window 

This version adds an interactive REPL window. The REPL window is based on the same REPL that is integrated with the Python and Node tools for Visual Studio. You can run commands just like you would in any other PowerShell command window. You can access the window via View->Other Windows->PowerShell Debug Interactive. Output from your PowerShell scripts now goes to this window rather than the Output pane.


Minor Bug Fixes and Changes

  • Fixed test discovery
  • Removed Project property pages because they were not actually functional
  • Added $DTE variable for StudioShell support and automation accessibility
Categories: Powershell

Thread Slivers eBook at Amazon

Syndicate content