Blogs|Jan 18, 2017

New WintellectPowerShell Version with Visual Studio 2017 Support

We have a new version of Visual Studio coming soon so I did the work to update my WintellectPowerShell module to support it. And, what a huge adventure that turned out to be! I will discuss why its support for Visual Studio 2017 was hard a bit later in this blog entry. For those of…
Read More→
news|Nov 25, 2015

Azure PowerShell 1.0 and Azure Portal Enhancements Released

Microsoft has released the 1.0 version of the Azure PowerShell cmdlets for automating processes with Azure including better support for Resource Manager, VM disk encryption with Azure Vault, and inclusion of Azure Data Lake and Notification Hub cmdlets.  Also released were new user experience improvements in the Azure Preview Portal such as notification enhancements and…
Read More→
Blogs|Nov 7, 2015

WintellectPowerShell Now on the PowerShell Gallery

Getting and installing modules is easier than ever with the PowerShell Gallery and PowerShellGet. Instead of downloading and extracting files into your PowerShell modules directory, a simple call to Install-Module takes care of everything for you. Today I’ve published my WintellectPowerShell module. Now you can install and get started setting up Visual Studio to access…
Read More→
Blogs|Dec 11, 2014

Single Stepping a PowerShell Pipeline

As I was building up a moderately complicated pipeline in PowerShell, I was having some trouble and really wished there was a way to single step the pipeline so I could see the state of each item as it was processed. I wasn’t sure this was possible, but it is and I thought others might find it helpful. The magic is in the super powerful Set-PSBreakpoint cmdlet.

Because Set-PSBreakpoint can create breakpoints on not only lines and variable reads/writes, but also commands, I thought I’d try setting a breakpoint in the PowerShell console on one of the commands in the pipeline and it worked great! In the example below I will set a breakpoint on the Get-ChildItem cmdlet and when the breakpoint is hit, use the command line debugger to step through parts of the pipeline (the ‘s’ command is step into)

  1. PS C:Junk> Set-PSBreakpoint -Command Get-ChildItem
  2.  
  3.   ID Script   Line Command        Variable    Action
  4.   -- ------   ---- -------        --------    ------
  5.    0               Get-ChildItem
  6.  
  7.  
  8. PS C:Junk> Get-ChildItem *.exe | ForEach-Object { $_.Name }
  9. Entering debug mode. Use h or ? for help.
  10.  
  11. Hit Command breakpoint on 'Get-ChildItem'
  12.  
  13. At line:1 char:1
  14. + Get-ChildItem *.exe | ForEach-Object { $_.Name }
  15. + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  16. [DBG]: PS C:Junk>> s
  17. At line:1 char:38
  18. + Get-ChildItem *.exe | ForEach-Object { $_.Name }
  19. +                                      ~
  20. [DBG]: PS C:Junk>> s
  21. At line:1 char:40
  22. + Get-ChildItem *.exe | ForEach-Object { $_.Name }
  23. +                                        ~~~~~~~
  24. [DBG]: PS C:Junk>> s
  25. Foo.exe
  26. At line:1 char:48
  27. + Get-ChildItem *.exe | ForEach-Object { $_.Name }
  28. +                                                ~
  29. [DBG]: PS C:Junk>>


I love how the tildes show you exactly where you are in the pipeline. That makes it super easy to debug the pipeline. A little hint when single stepping pipelines is if you are setting a command breakpoint on something like Get-ChildItem, you’re going to hit it all the time. What I found works best is writing the commands in the ISE and pasting them into the console window where you want to debug.

For those of you that use the ISE most of the time, you have one problem. Here’s the same commands run in the ISE.

  1. PS C:Junk> Set-PSBreakpoint -Command Get-ChildItem
  2.  
  3.   ID Script   Line Command        Variable    Action
  4.   -- ------   ---- -------        --------    ------
  5.    0               Get-ChildItem
  6.  
  7.  
  8. PS C:junk> Get-ChildItem *.exe | ForEach-Object { $_.Name }
  9. Hit Command breakpoint on 'Get-ChildItem'
  10. Stopped at: Get-ChildItem *.exe | ForEach-Object { $_.Name }
  11. [DBG]: PS C:junk>> s
  12.  
  13. Stopped at: Get-ChildItem *.exe | ForEach-Object { $_.Name }
  14. [DBG]: PS C:junk>> s
  15.  
  16. Stopped at: Get-ChildItem *.exe | ForEach-Object { $_.Name }
  17. [DBG]: PS C:junk>>


For whatever reason, the ISE does not show the tildes where you are in the pipeline. Fortunately, it’s not hard to find where you are because the $PSDebugContext variable’s InvocationInfo field has all the information about everything going on at that point in the debugger.

  1. [DBG]: PS C:junk>> $PSDebugContext.InvocationInfo
  2.  
  3.  
  4. MyCommand             :
  5. BoundParameters       : {}
  6. UnboundArguments      : {}
  7. ScriptLineNumber      : 1
  8. OffsetInLine          : 40
  9. HistoryId             : 3
  10. ScriptName            :
  11. Line                  : Get-ChildItem *.exe | ForEach-Object { $_.Name }
  12. PositionMessage       : At line:1 char:40
  13.                         + Get-ChildItem *.exe | ForEach-Object { $_.Name }
  14.                         +                                        ~~~~~~~
  15. PSScriptRoot          :
  16. PSCommandPath         :
  17. InvocationName        :
  18. PipelineLength        : 0
  19. PipelinePosition      : 0
  20. ExpectingInput        : False
  21. CommandOrigin         : Internal
  22. DisplayScriptPosition :


As you can see, the PositionMessage is the important data. In my ISE profile, I added the following function to make it easy to see where I’m at when single stepping a pipeline.

  1. function cpo
  2. {
  3.     if (test-path variable:/PSDebugContext)
  4.     {
  5.         $PSDebugContext.InvocationInfo.PositionMessage
  6.     }
  7. }


Single stepping the pipeline isn’t super ninja magic like some of those PowerShell people do but this sure helped me figure out what was going on in my troublesome pipeline.

Read More→
resources|Oct 12, 2013

Wintellect PowerShell Module

PowerShell scripts for better debugging and life! This module provides cmdlets for setting up symbol servers and other functionality related to debugging. This module makes setting up symbol servers and source server debugging functionality easier to control for Visual Studio 2010, Visual Studio 2012 and WinDBG. Setting up a development machine for symbol server access…
Read More→
Blogs|May 9, 2013

Visual Studio vs. the PowerShell Command Line

Numerous times in the last month I’ve been working with different teams and when I whip out my PowerShell window and start doing all the magic, especially with Visual Studio command line tools, the young kids go crazy. The mix of command line development tools and PowerShell is a powerful aphrodisiac. Too bad that Visual…
Read More→
Blogs|Jan 28, 2013

Batch Updating/Changing Visual Studio Projects with PowerShell

Working on a giant codebase recently, I needed to check if all C# projects had Code Analysis turned on for all configurations. Given there were easily 30 to 40 different .CSPROJ files I was so not looking forward to manually going through them all one at a time in Visual Studio to check. The .CSPROJ…
Read More→
Blogs|Jan 27, 2013

Find File and Directory Names FAST

For some reason, I always seem to be looking for file and directory names. Since desktop search is a GUI and I’m a command line kind of guy, I got tired of waiting on PowerShell to slowly grind through the file system on its single thread. With lots of cores and an SSD, I shouldn’t…
Read More→
wintellect-blogs|Dec 21, 2012

Start-PowerShellPoint Now on GitHub

A couple of years ago I was messing around and decided when doing a presentation on PowerShell for Developers only losers would use PowerPoint, but I needed to show bullet points and URLs. Thus, Start-PowerShellPoint was born! The first rule of PowerShell is to ALWAYS use PowerShell. Lots of people found it funny. I’d had…
Read More→