For the next three Wednesdays, we will be teaming up with Manning Publishing to take a deep dive into PowerShell. These lessons are advanced. Because I do not come from a scripting background, I found them very useful! If you don’t come from a scripting background and want to learn more about PowerShell, take a look at these two books that explain PowerShell in English! Pretty much any script you see on this site uses techniques and logic from both of those books.
In this series, we will be covering the extremely helpful technique of extending PowerShell through the use of .NET code. These excerpts come from the new book, PowerShell Deep Dives by Jeffery Hicks, Richard Siddaway, Oisín Grehan, and Aleksandar Nikolić. Stay with me through this series – while you won’t get a case of the bends, you will learn some great new PowerShell tricks!
This section was written by Richard Siddaway:
PowerShell is .NET-based. This enables you to use the .NET framework in your PowerShell scripts by loading the relevant assemblies into PowerShell (if they aren’t part of the default assembly set) and then using them via New-Object. You can create intricate GUI applications as a front end to your scripts, for instance. You can also use .NET code directly in your scripts.
One way to use .NET directly in your scripts involves creating a .NET class that you can then use for output or future processing. The second way enables you to create a class with methods you can use in your script to perform an action. You could access the method without creating a class, but ultimately, creating the class gives you more flexibility. Let’s start by looking at how to create a class for output.
.NET class for output
The PowerShell mantra is output objects. Executing a simple piece of PowerShell such as the following produces output onscreen:
Get-CimInstance -ClassName Win32_OperatingSystem | select CSName, Caption, OSArchitecture, LastBootUpTime, CountryCode CSName : RSLAPTOP01 Caption : Microsoft Windows 8 Enterprise OSArchitecture : 32-bit LastBootUpTime : 17/08/2012 10:02:11 CountryCode : 44
Output types
If you look at the output type by piping this code into Get-Member you’ll see it’s a Selected.Microsoft.Management.Infrastructure.CimInstance object. It’s a modified version of the object produced by the Get-CimInstance cmdlet but still an object that can be put onto the PowerShell pipeline for further processing.
Such output is common when investigating computer configuration. Another common requirement is to retrieve information about the computer hardware. Here’s an example:
Get-CimInstance -ClassName Win32_ComputerSystem | select DNSHostName, TotalPhysicalMemory, Manufacturer, Model, Domain DNSHostName : RSLAPTOP01 TotalPhysicalMemory : 2951135232 Manufacturer : Hewlett-Packard Model : HP G60 Notebook PC Domain : WORKGROUP
Outputting single objects is straightforward. When working interactively, outputting multiple objects in a sequential manner is easy. What happens when you run these two sets of code in a script? The two WMI classes work together, but you can get a formatting error because the default formats for the two classes clash. Also, outputting two objects from a single script or advanced function makes further processing of the output problematic if not impossible.
That is a short introduction to expanding Inline .NET code in PowerShell! Over the next two weeks, we will cover two very cool (and lengthy) examples! If you are interested in other tricks like this, check out the newly released PowerShell Deep Dives
As a note, some links above are affiliated and used to support this site.