Nate Kasco

The other day we laid out the design for our PS Event Viewer utility, today for part 2 we will be designing and configuring. For this project I decided to leverage PoshGUI, which is great for quickly creating standalone forms. It definitely has it’s limitations, for example what if your form grows and shrinks? You would probably want to use a TableLayoutPanel with dock properties set to ‘fill’ so that you don’t have to guess the sizes of the objects as the form grows/shrinks. In this case…

At one point or another you’ve probably heard of Pester. Pester is great for streamlining unit and acceptance testing and is versatile enough to work with both real and mock data. The problem I’ve often run into is knowing when (and when not) to leverage Pester to create additional tests. For me, it came down to asking myself 1 thing… Does the underlying technology that your code is built upon constantly change? 

If you’ve ever created a WinForm GUI in Powershell you’ve probably dealt with not being able to click the X on the Form to close a hung command. Even by running the command separate from the GUI in a job or runspace you still need a way to force close your tool. An easy go-to might be to just kill powershell.exe, but what if you have multiple instances, how you do know which one to kill?