In SharePoint and PowerShell Demo – Part 1 we looked at a custom cmdlet, Select-FeatureDefininition, which took a string value of an unknown Feature Id and returned the associated FeatureDefinition to the console. We also viewed how the Feature Id could be passed into the cmdlet via the pipeline allowing us to be more creative with our commands.
Now continuing on from Part 1 .
What is very interesting about PowerShell and what makes PS completely different from other command line shells is the pipeline. The pipeline passes the output of one command to be used as the input for the next command. What is vastly different here is that the output is not text. The output is usually a rich object with properties and methods.
The last example in Part 1 showed two guids being piped into the Select-FeatureDefinition cmdlet (which is a type of command). These guids were passed in as objects and accepted as input. It is easy to believe that the string-valued GUIDs are being passed in as simple text but they are really passed as .Net objects. Lets look at another example using Select-FeatureDefinition.
The following screenshot is the result of running:
Select-FeatureDefinition (“00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5”) | Get-Member.
If you look closely at the output above you can see that it is the methods and properties of the SPFeatureDefinition type from the Microsoft.SharePoint assembly. How does this work? The output of the Select-FeatureDefinition is not simply text or strings sent to the console (or host) as it appears to be in previous examples. It is actually outputting a SPFeatureDefinition object, more specifically the SPFeatureDefinition object that was found to be associated with the GUID passed in. In this demo we simply asked PowerShell via the Get-Member command to reflect into the object (SPFeatureDefinition) and output the result as objects.
So there is two “key” points here.
1. PowerShell can reflect into .Net objects
2. Objects are the output and not text
Point is pretty obvious from the last screenshot as we can see the properties and methods of the SPFeatureDefinition object. Point 2 should be obvious. The Select-FeatureDefinintion command is the command that finds the correct FeatureDefinition. In order for Get-Member command to be able to output the properties and methods it must have access to the object. The object must come from the Select-FeatureDefinition command via the pipeline.
To further prove the point that output is objects and not text ( I think this is a very key point) lets build on our previous command by adding another Get-Method command to the pipeline. This time the commands will look like :
Select-FeatureDefinition (“00BFEA71-4EA5-48D4-A4AD-7EA5C011ABE5”) | Get-Member | Get-Member
The figure below displays the host output.
From the console output we can see that we are reflecting not into strings or text but into an object of type Microsoft.PowerShell.Commands.MemberDefininition. The point here? Even when we call Get-Member on an object and the output appears to be text, the output is still an object. Since the output is really a type and not text we can continue to process the objects using scripts and commands. You cannot do this easily in other command line tools or shells such as STSADM.exe or CMD.exe!
So if every output ( or nearly every output) is an object and not text why are we seeing text? That will have to wait for the next post. Until then just keep thinking “Objects”!