It seems like more and more I am seeing people wanting to implement GUIs into their tools, my hope is that this example can be used as a model for a way to properly create a WinForm GUI for your shiny new utility that you just got done creating.
In this multi-part series I will be going through from start to finish a replacement tool for Windows Event Viewer…
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?