Cmdlets differ from commands in other shell environments in the following ways:

• Cmdlets are instances of .NET classes, not stand-alone executables.

• Cmdlets can be created with as few as a dozen lines of code.

• Cmdlets do not, in general, do their own parsing, error presentation, or output formatting. Parsing, error presentation, and output formatting are handled by the Windows PowerShell runtime.

• Cmdlets process input objects from the pipeline rather than from streams of text, and they typically deliver objects as output to the pipeline.

• Cmdlets are record-oriented, processing a single object at a time.

Windows PowerShell supports cmdlets that are derived from two different base classes:

• Most cmdlets are based on .NET classes that derive from the Cmdlet base class. Deriving from this class means that your cmdlet is using the minimum set of dependencies on the Windows PowerShell runtime. This has two benefits. First, your cmdlet objects are smaller and you are less likely to be impacted by changes to the Windows PowerShell runtime. Second, if you have to, you can directly create an instance of the cmdlet object and invoke it directly instead of invoking it through the Windows PowerShell runtime.

• More complex cmdlets are based on .NET classes that derive from the PSCmdlet base class. Deriving from this class gives you much more access to the Windows PowerShell runtime. This access allows your cmdlet to call scripts, access providers, and access the current session state (getting and setting session variables and preferences). However, it also increases the size of the cmdlet object, and it means that your cmdlet is more tightly coupled to the current version of the Windows PowerShell runtime.

In general, unless you need the extended access to the Windows PowerShell runtime, you should derive from the Cmdlet class. However, the Windows PowerShell runtime has extensive logging capabilities for the execution of cmdlets. If your auditing model depends on this logging, then you want to prevent the execution of your cmdlet from within another cmdlet by deriving from the PSCmdlet class

The Cmdlet class provides the following virtual methods used to process records. One or more of these process record methods must be overridden by all derived cmdlet classes:

• BeginProcessing: Used to provide optional one-time, pre-processing functionality for the cmdlet.

• ProcessRecord: Used to provide record-by-record processing functionality for the cmdlet. ProcessRecord might be called any number of times, or not at all, depending on the input of the cmdlet.

• EndProcessing: Used to provide optional one-time, post-processing functionality for the cmdlet.

• StopProcessing: Used to stop processing when the user stops the cmdlet asynchronously (such as by entering the key combination CTRL+C).

For more information about declaring cmdlets, see Cmdlet Declaration.

Windows PowerShell defines several .NET attributes that are used to manage cmdlets and to offload common functionality that might be required by the cmdlet. For example, attributes are used to designate a class as a cmdlet, to specify the parameters of the cmdlet, and to request the validation of input so that cmdlet developers do not need to implement that functionality in their cmdlet code. For more information about attributes, see Windows PowerShell Attributes.

Windows PowerShell uses a verb and noun name-pair format to name cmdlets. For example, the Get-Command cmdlet provided by Windows PowerShell is used to get all the cmdlets registered in the shell. As you can see, the verb name identifies the action that the cmdlet performs and the noun name identifies the entity on which the cmdlet performs its action.

These names are specified when the .NET class is declared as a cmdlet. For more information about declaring a .NET class as a cmdlet, see Cmdlet Declaration.

For more information about writing cmdlets, see How to Create a Windows PowerShell Cmdlet. This guide provides several examples of how to write cmdlets, starting with a basic cmdlet and ending with a cmdlet that accesses a data store through a Windows PowerShell provider.

For more information about guidelines for writing cmdlets, see Cmdlet Development Guidelines.

For more information about how Windows PowerShell works, see How Windows PowerShell Works in the Windows PowerShell Programmer's Guide.

Concepts

Other Resources