Blogs|Mar 4, 2015

ng-init @ ng-conf 2015

ng-conf: Day 0 It’s only the first day at ng-conf 2015 but I am already pretty pumped about the next few days. There are of course going to be some cool things going on tonight even before the conference gets started. For instance there is a pretty interesting “Building Microsoft Office Apps with AngularJS Hackathon”…
Read More→
Blogs|Mar 2, 2015

Responding to Orientation Changes in Xamarin Forms

Last week, I published the first in a series of articles on building cross-platform mobile apps with Visual Studio 2015 and Xamarin Forms. In it, I presented an RPN calculator app that works on Windows Phone, Android, and iOS. One subject I didn’t address in that article was how to respond to orientation changes in…
Read More→
Blogs|Feb 19, 2015

Software Development Guidelines to Live By

Not too long ago I posted a tweet that immediately went viral. (OK, it’s all relative – to me 66 retweets and 120 favorites is viral.)  It referred to Microsoft’s Engineering Guidelines for contributing to its open-source repository on GitHub for the next version of its web development platform, ASP.NET 5. You may be familiar…
Read More→
Blogs|Feb 10, 2015

Implementing Interfaces in F# Using Object Expressions

To expand on another topic that was mentioned in the F# Infographic is that F# also has the ability to use any .NET library. From that, you may be wondering, “what about implementing interfaces that may come in other libraries?” Of course, you can create classes in F# if you need but there’s a more…
Read More→
developer-lifestyle|Feb 8, 2015

Modern Web Development 101

Maybe you’ve heard the term “Modern Web” before. It embodies the idea of a constantly evolving, exciting platform that unique and powerful user experiences can be built upon. It is a platform that new capabilities are added to regularly, not waiting for long release cycles. And maybe you’ve been asked to build a “modern web…
Read More→
Blogs|Feb 5, 2015

Cmder: Making the Command Line Your Best Friend

Now that I’ve jumped fully on board the Git and GitHub bandwagon, I’m spending a lot more time at the command line.  In fact, I find myself working with both Visual Studio and the command prompt simultaneously, constantly switching back and forth between the two.  The main reason is that, while Visual Studio 2013 makes…
Read More→
Blogs|Jan 22, 2015

Why You Should Be Writing ECMA Script 6 Now

If you are reading this article then you have probably at least heard of ECMA Script 6, the next version of JavaScript, and are curious about what it means for you or your organization. You might be wondering how ES6 is different, if it will affect your existing applications, or if it will affect your…
Read More→
Blogs|Jan 21, 2015

When Should You Make the Move to Entity Framework 7?

The next version of Entity Framework will be called “Version 7” and will be released as part of the next version of ASP.NET, called “ASP.NET 5.” If you’re currently on EF6, you might jump to the conclusion that you should upgrade to EF7 as soon as it hits the streets. But the EF team has…
Read More→
Blogs|Dec 31, 2014

Less Defects with F# Units of Measure

One of the most powerful things that F# has is its ability to create custom units of measure. F# allows you to set an explicit type to a unit. That’s right…you will get compile time checking on any of the units that you use within your app...
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→