Reflecting on PowerShell in SharePoint 2010

  • Article

As we all know, sometimes we just get stuck trying to figure out how to get from point A to point B when working through some SharePoint coding scenario.  One of the things that comes up more frequently in this regardin in SharePoint 2010 has to do with the PowerShell cmdlets that are used so prevalently throughout the product.  Many of you know how to use Lutz's Reflector tool to look at code in the SharePoint DLLs to understand better what's going on or how to do something.  But wouldn't it be nice to do the same thing with those PowerShell cmdlets?  Well it turns out you can.  I'm going to show you how to do that, along with another useful trick once you get it loaded up.

The key thing to remember here is that the PowerShell cmdlets are just implemented in DLLs like any other managed code.  The main PowerShell assembly for SharePoint is called microsoft.sharepoint.powershell.dll.  If you do a little snooping around on your hard drive though you will have a hard time finding it.  That's because at install time the assembly is only placed in the global assembly cache.  So in order to use it with Reflector, here's what I do:

  1. Open a command prompt.
  2. Change to the root of your system drive (we'll assume the C:\ drive for simplicty here)
  3. Do a deep directly search for the file - i.e., "dir microsoft.sharepoint.powershell.dll /s"
  4. You will eventually see the temporary directory the GAC has created and stored the dll.  Copy the dll to a fixed folder location; I just copy it back to c:\.

Now you that have the SharePoint PowerShell dll, you can load it up in Reflector and see what those PowerShell cmdlets are doing under the cover.  This can be VERY helpful when trying to figure out the who/what/where of how to target your OM code.  Now here's tip #2 - you have the assembly loaded in Reflector.  You run some PowerShell command and want to look at it, but you can't find it in the listing of methods for microsoft.sharepoint.powershell.dll.  Maybe it isn't in there, or maybe you just don't know what the name of the method is that it's calling.  This is actually a pretty common occurrence.  It happens because not every PowerShell cmdlet is included in that one assembly.  So with all of the assemblies that ship with SharePoint, how do you find the one that has the cmdlet you're looking for?  That's tip #2 - what you do is execute the command but supply an invalid value for one of the parameters.  Most cmdlets take an "Identity" parameter, so I usually just run the command with an -Identity "asdfasdf" parameter.  What generally happens is that it tells you the parameter is invalid...along with the name of the method it tried to execute and the assembly it lives in.  For example, when I run Get-SPTrustedIdentityTokenIssuer -Identity "fasdfas", it tells me that the method it's calling is SPCmdletGetSPIdentityProvider, and it's in the Microsoft.SharePoint.PowerShell assembly.  When I run Get-SPEnterpriseSearchServiceApplication -Identity "fasdf", it tells me that it is calling the GetSearchServiceApplication in the Microsoft.Office.Server.Search assembly.  So then it's easy enough to find that assembly on disk, load it in Reflector, and find the method I'm looking for.

These are kind of hacky, but useful tricks to get you through your development day.