The first question to ask is when to create cmdlets?

A cmdlet allows a farm administrator to manage and administer the SharePoint farm (s) quickly from a PowerShell console.

If you have specific tasks, which you run in batches and this is frequent, you have a context conducive to this creation. Otherwise do not waste your time creating cmdlets that will end up in the closet quickly, instead try to push the possibilities of PowerShell and go through functions to get you out. 


There are many other situations with SharePoint that require the creation of new cmdlets

  • New management capabilities (site, list, permissions, etc.)
  • Creation of a new service
  • Interoperability with third-party tools (eg Backup Exec, etc.) )

With SharePoint, you have several choices when designing your cmdlet since the platform offers several classes already specialized according to your intention:

  1. SPCmdletBase (derived from System.Management.Automation.PSCmdlet)
  2. SPCmdletPipeBind<TCmdletObject>
  3. SPGetCmdletBase<TCmdletObject>
  4. SPNewCmdletBase<TCmdletObject>
  5. SPRemoveCmdletBase<TCmdletObject>
  6. SPSetCmdletBase<TCmdletObject>


To point you, one of the criteria to consider is the use of persistence between your cmdlets: does the cmdlet return an object(like list) that will be stored in a variable? If this is the case, use the derived classes of SPCmdletBase, which are:

  1. SPGetCmdletBase<TCmdletObject> – Method to override “protected override SPWeb RetrieveDataObjects()”
  2. SPNewCmdletBase<TCmdletObject> – Method to override “protected override SPWeb CreateDataObject()”
  3. SPRemoveCmdletBase<TCmdletObject>
  4. SPSetCmdletBase<TCmdletObject>

If your cmdlet does not return a specific object, but only performs actions (such as updating permissions, displaying a report in unstructured text output, etc.), using the SPCmdlet class will be more appropriate.

If you want to use the PowerShell pipeline system to chain your order, the all-inclusive class to this will be SPCmdletPipeBind. We will use it in our example.


If you have any custom objects that can be represented using more than one mechanism (a URL and a GUID, for example), you should consider creating a custom PipeBind object so that either representation of the object can be passed to your cmdlet.

A common example of a PipeBind object is the SPSitePipeBind object that is used whenever an sPSite object is needed. The SPSitePipeBind type allows a URL, a GUID, or an actual snite object to be passed into any SPSitePipeBind parameter.

To create a custom PipeBind object, you inherit from SPCmdletPipeBind<TCmdletObject>. You must then have at least one public constructor that can be used by the PowerShell run time to load the parameter specified. When the run time parses the parameter, it attempts to bind it to a con-structor that matches the parameter type. If no constructor can be found, an error is thrown.

You must also override the Read ( ) and Discover (TCmdletObject ) methods. The Read ( ) method inspects the values stored by the constructors, and returns an object of the specified type. The Discover (TCmdletObject) method takes in an object and should store the object, or an alternate representation of the object, which can then be used when the Read ( ) method is called.


In this part, we will create a simple example, a cmdlet to list the contents of a list. We have chosen to use the base class SPGetCmdletBase which will be used in conjunction with SPCmdletPipeBind to retrieve the address parameter from the list


When the SharePoint PowerShell snap-in is loaded, it looks at all the XML files in the {SharePointRoot}\CONFIG\PowerShell\Registration folder. The solution package will deploy a custom XML file defining custom cmdlets to this folder.

  1. Right-click the project file in the Solution Explorer and select Add I SharePoint Mapped Folder – {SharePointRoot}\CONFIG\PowerShell\Registration.
  2. Right-click the Registration folder and select Add> New Item.
  3. In the Add New Item dialog, select Installed Templates > Visual C# > Data > XML File.
  4. Name the file SPListCmdletDemo.xml and click Add to add the file.
  5. Open the new XML file and add the following XML to the file



After the project is created and compiled, deploy the project (right click on the project> Deploy) and run a PowerShell command (you will have to open a new console after each deployment) and test the following commands

  • Get-SPList http://webApplication/Lists/Configurations
  • Get-SPList http://webApplication/Lists/Configurations -ShowFields
  • Get-SPList http://webApplication/Lists/Configurations -QueryFields “Title; Author”


Instead, we may also create it as a PowerShell snapin to avoid XML configurations.