This programmer's guide is targeted at developers who are interested in providing a command-line management environment for system administrators. Microsoft® Windows® PowerShell provides a simple way for you to build management commands that expose .NET objects, while allowing Windows PowerShell to do most of the work for you.
In traditional command development, you are required to write a parameter parser, a parameter binder, filters, and all other functionality exposed by each command. Windows PowerShell provides the following to make it easy for you to write commands:
At little cost, you can represent a .NET object by a rich command or set of commands that will offer a complete command-line experience to the administrator.
The next section covers the key Windows PowerShell concepts and terms. Familiarize yourself with these concepts and terms before starting development.
Windows PowerShell defines several types of commands that you can use in development. These commands include: functions, filters, scripts, aliases, and executables (applications). The main command type discussed in this guide is a simple, small command called a "cmdlet". Windows PowerShell furnishes a set of cmdlets and fully supports cmdlet customization to suit your environment. The Windows PowerShell runtime processes all command types just as it does cmdlets, using pipelines.
In addition to commands, Windows PowerShell supports various customizable Windows PowerShell providers that make available specific sets of cmdlets. The shell operates within the Windows PowerShell-provided hosting application (Windows PowerShell.exe), but it is equally accessible from a custom hosting application that you can develop to meet specific requirements. For more information, see How Windows PowerShell Works.
Windows PowerShell Cmdlets
A Windows PowerShell cmdlet is a simple command used for interaction with any managed application, including the operating system. It is analogous to a built-in command in another shell, such as Cmd.exe, KSH, or BASH. The traditional shell generally processes commands as separate executable programs. Each program has to parse the input, distinguish between positional and named parameters, bind values to the correct parameters, format the output, and display the output.
In contrast, Windows PowerShell processes commands as instances of a .NET class, focusing on the simple cmdlet model. You must provide the parameters and validate the values, and then furnish details of object types and formatting. Windows PowerShell does the rest of the work: parsing the parameters, binding them to their values, formatting the output, and displaying the output.
A user of Windows PowerShell can run a cmdlet singly or as one of several cmdlets piped together on the command line. Just to familiarize you with the use of a cmdlet before you begin developing, the following example shows the syntax for execution of the Get-Process cmdlet shipped with Windows PowerShell. This cmdlet retrieves processes and displays them in the console window.
PS>get-process
The next example shows the syntax to execute the piped Get-Process and Stop-Process cmdlets. First the Get-Process cmdlet retrieves the processes named "notepad" and then the Stop-Process cmdlet stops those processes.
PS>get-process notepad | stop-process
For more information about command processing, see How Windows PowerShell Works. For more information about developing cmdlets, see How to Create a Windows PowerShell Cmdlet.
Windows PowerShell Providers
In performing administrative tasks, the user may need to examine data stored in a data store (for example, the file system, the Windows Registry, or a certificate store). To make these operations easier, Windows PowerShell defines a module called a Windows PowerShell provider that can be used to access a specific data store, such as the Windows Registry. Each provider supports a set of related cmdlets to give the user a symmetrical view of the data in the store.
Windows PowerShell provides several default Windows PowerShell providers. For example, the Registry provider supports navigation and manipulation of the Windows Registry. Registry keys are represented as items, and registry values are treated as properties.
If you expose a data store that the user will need to access, you might need to write your own Windows PowerShell provider, as described in How to Create a Windows PowerShell Provider. For more information about Windows PowerShell providers, see How Windows PowerShell Works.
Hosting Application
Windows PowerShell includes the default hosting application powershell.exe, which is a console application that interacts with the user and hosts the Windows PowerShell runtime using a console window. Hosting application operational details are provided in How Windows PowerShell Works.
Only rarely will you need to write your own hosting application for Windows PowerShell, although customization is supported. One case in which you might need your own application is when you have a requirement for a GUI interface that is richer than the interface provided by the default hosting application. You might also want a custom application when you are basing your GUI on the command line. For more information, see How to Create a Windows PowerShell Hosting Application.
Windows PowerShell Runtime
The Windows PowerShell runtime is the execution engine that implements command processing. It includes the classes that provide the interface between the hosting application and Windows PowerShell commands and providers. The Windows PowerShell runtime is implemented as a runspace object for the current Windows PowerShell session, which is the operational environment in which the shell and the commands execute. For operational details, see How Windows PowerShell Works.
Windows PowerShell Language
The Windows PowerShell language provides scripting functions and mechanisms to invoke commands. For complete scripting information, see the Windows PowerShell Language Reference shipped with Windows PowerShell.
Extended Type System (ETS)
Windows PowerShell provides access to a variety of different objects, such as .NET and XML objects. As a consequence, to present a common abstraction for all object types the shell uses its extended type system (ETS). Most ETS functionality is transparent to the user, but the script or .NET developer uses it for the following purposes:
-
Viewing a subset of the members of specific objects. Windows PowerShell provides an "adapted" view of several specific object types.
-
Adding members to existing objects.
-
Access to serialized objects.
-
Writing customized objects.
Using ETS, you can create flexible new "types" that are compatible with the Windows PowerShell language. If you are a .NET developer, you are able to work with objects using the same semantics as the Windows PowerShell language applies to scripting, for example, to determine if an object evaluates to true.
For more information about ETS and how Windows PowerShell uses objects, see Windows PowerShell Object Concepts and Windows PowerShell Extended Type System (ETS).