Ever wondered how the Microsoft guys code their powershell CMDLets? Ever wanted to take a peek at the implementation of a Powershell command? "Then take the red pill, stay in wonderland and I show you how deep the rabbit hole goes. Remember: all I'm offering is the truth. Nothing more."
Everything starts with the Get-Command CMDlet. Using Get-Command you can figure out a lot of properties of the command you want to look behind. The most important thing we need to know about a command is its type. The way to get to the script code is different for each command type. There are a lot of command types but most Powershell commands are of type "CMDLet" or "Function". Another command type is "Alias". But this is just a refenrence to a "CMDLet" or "Function". So let's focus on these two for now.
For this walkthrough I picked the "GC" (Get-Content) command as example for a CMDLet and "Get-WindowsUpdateLog" as an example for a Function.
The CMDLet inside a .NET binary
Let's start to x-ray "Get-Content" by opening a Powershell window (doesn't need to be elevated) and typing the following command:
Get-Command gc | fl *
Using the short form "GC" with Get-Command, like we just did, shows "Alias" as CommandType property. To figure out the full name of the command, take a look at the "ResolvedCommandName" property and repeat Get-Command with its value. Using the long form shows the real command type, in this case a CMDLet.
Get-Command Get-Content | fl *
The DLL property of the output indicates where the implementation of this CMDLet can be found. Since this is a binary format (.DLL), we need a disassembler to continue. There are a lot of tools to disassemble a dotNet binary. I use ILSpy. It's fast and can be installed as a portable app (no installation necessary).
So let's open the file from the DLL property (Microsoft.PowerShell.Commands.Management.dll) in ILSpy. Most times the command implementation is found in the "Microsoft.PowerShell.Commands" namespace.
From now on a little knowledge about .NET programming is necessary but as a rough indication we can search for methods like "ProcessRecord" or "BeginProcessing" to get a starting point.
The Function way
It's different when we need to get the source code for a command implemented as a function. As mentioned at the beginning, we use the "Get-WindowsUpdateLog" as an example here. So let's have a look at its members.
Get-Command Get-WindowsUpdateLog | fl *
The source code of the function itself can be found in the "Definition" property. So it can easily be displayed using the command:
Get-Command Get-WindowsupdateLog | select -ExpandProperty Definition
However, in many cases, the function is using code parts or other functions from its parent module. To view the complete source code, we need to open the whole module in a text editor.
First, let's find the parent module:
Get-Command Get-WindowsUpdateLog | select -ExpandProperty ModuleName
It's part of the "WindowsUpdate" module. But where to find it? Well, that's easy:
Get-Module -Name WindowsUpdate | select -ExpandProperty Path
This displays the path to the module manifest or module definition file (*.psd1). Let's open the PSD1 file in a text editor.
Find the line "ModuleList" or "NestedModules". In both of them you can figure out the path to the module files (*.psm1). The module files normally reside in the same directory. One of those files contains the implementation of the function, found in the definition property of the Get-Command output. In our case it's easy because this psd1 only contains one module. So let's go and open the PSM1 file in our favorite text editor.
Here we have the complete implementation of our function.
You may have noticed, that I used the terms "normally, most times..." quite often in this tutorial. This is because the implementaion of CMDLets is not fully standardized. Finding the way back to other commands could slightly differ to the steps mentioned above. Anyway it's good starting point.
This post first appeared on MSDN Blogs | Get The Latest Information, Insights, Announcements, And News From Microsoft Experts And Developers In The MSDN Blogs., please read the originial post: here