Introduction to .NET Framework 3.0/Windows PowerShell

Introduction to .NET Framework 3.0

Preface — An Overview — Advantages of .NET 3.0 — An Overview of Master Pages — Caching — Generics — Nullable Types — Windows Presentation Foundation — Windows Communication Foundation — Windows Cardspace — Windows Workflow Foundation — Features of IIS 7.0 — Windows Powershell

Windows PowerShell (codenamed:Monad) is a command-line driven interface (CLI). It is not supplied with older versions of Windows Vista, but it could be used, regardless, in Windows XP, Windows 2003 Server and Windows Vista.

Windows PowerShell is the foundation of the administrative tools for Exchange Server 2007, System Center Virtual Machine Manager 2007 and System Center Operations Manager 2007 where everything is done via command line interfaces and the administrative GUI is layered on top of those commands.

Working

Windows PowerShell works according to a system called "Monadology" according to which the whole earth is composed of metaphysical structures not connected to each other called monads. The "monads" of Windows PowerShell are objects called "cmdlets". Following the failure of Windows Script Host, Microsoft started working on Windows PowerShell as early as 2003. Unlike Windows Script Host, Windows Powershell interacts directly with the shell and is highly secure.

Instead of services which use pipes or streams data in order to communicate with each, Windows Powershell uses object-to-object communication between two cmdlets in different remote machines. A listing of processes will consist not of text describing them, but objects representing them, so that methods can be called on those objects without explicit reference to any outside structure or library.

Windows PowerShell operates within a hosting application (the default is powershell.exe) that exposes a command line to the user and uses a host interface to communicate with the commands invoked by the command line. The hosting application can be a console application, a Windows application, or a Web application. In most cases, the hosting application uses its Main function to interact with the Windows PowerShell runtime through the internal host interface; however, a hosting application can optionally support its own custom host by implementing the PSHost class along with one or more related user interface classes. Together, these classes allow direct communication between the application and Windows PowerShell commands.

Creating a Runspace

The first thing that the hosting application must do in communicating with the Windows PowerShell runtime is to create a runspace, which is the abstraction of the Windows PowerShell runtime used to simplify a user session. To do this, the hosting application calls the CreateRunspace method of the RunspaceFactory class. The runspace itself is represented by a Runspace object. In addition, Windows PowerShell provides the RunspaceConfiguration class to define the configuration of the runspace. Configuration information includes data about commands and Windows PowerShell providers that the hosting application supports, and startup scripts for the runspace. User scripts are not reflected in the runspace configuration. When a runspace is created, a corresponding session is automatically opened, with its state represented by a SessionState object. Session state data includes information about Windows PowerShell paths, Windows PowerShell drives, Windows PowerShell providers, plus cmdlets and other commands that are active during the session.

Opening the Runspace

When the hosting application has created a runspace, it must open the runspace for the type of session that is required. For a session using synchronous I/O, the application can call the Open method. If the application uses asynchronous I/O and must perform other operations while the runspace fulfills a read/write request, it can call the OpenAsync method. If calling OpenAsync, a hosting application defining a custom host will need to support an appropriate callback method to receive I/O notifications.

When the runspace is opened, the hosting application can manipulate the session by creating and invoking pipelines in the runspace, as described in Processing Commands.

The runspace allows the hosting application to manipulate the session with calls to the GetVariable and SetVariable methods of the SessionStateProxy object for the session.

Creating a Pipeline

When the hosting application has accumulated a command sequence from the user, it must form the commands into one or more pipelines, each represented by a Pipeline object for the active runspace.

A command sequence can be made up of multiple nested pipelines, separated by semicolon (;) statement separators. Here's an example of such a sequence.

PS>pqr | bar; a | b

The Windows PowerShell runtime represents this sequence as one pipeline with two nested pipelines, pqr | bar and a | b.

To create its own pipeline, the hosting application calls either the CreatePipeline method or the CreateNestedPipeline method. The application calls CreatePipeline to form an empty pipeline or if it must create a pipeline and populate it with commands. If the application must create a pipeline for a runspace with its current pipeline executing, it must call CreateNestedPipeline.

Starting the Pipeline

Now that its pipeline is set up, the hosting application must start its operation. If the application is using synchronous I/O, it calls the Invoke method, using the variant for either an empty pipeline or a populated one. For asynchronous I/O, the application can call InvokeAsync instead.

Features

The first version contains the following features:

A C#-like scripting language with support for hash tables, switch statements which can test on regular expressions, array slicing and anonymous methods (script blocks) which can be stored as data and then later executed. It also provides looping (for/foreach/while), conditional statements (if/switch), variable scoping (global/script/local) and the ability to define functions.
Cmdlets inherit certain options, allowing the user to choose things such as the level of interaction and how to deal with errors. Cmdlets which produce side effects support the options -WhatIf and -Confirm. -WhatIf informs the user what would have happened, but no action takes place. -Confirm informs the user what is about to happen and allows the user to control whether it takes place or not.
One option for dealing with errors is to invoke a "suspend" feature which allows the user to enter a new command shell, investigate a problem, and resume the original command. The user can define the prompts to be shown in such circumstances.
An extensible provider model allows access to and manipulation of the file system and other hierarchical data stores. Some examples: PowerShell comes with a registry provider which allows access to the registry via the "HKLM" and "HKCU" hives; with this, the registry can be browsed by executing commands like "dir HKLM:\SOFTWARE\Microsoft" at the shell prompt. PowerShell comes with providers for the certificate store, the environment, and shell functions and aliases. Like cmdlets, the provider model is extensible, allowing third parties to create their own provider model and plug it into PowerShell.
A concept called "execution policies" which allows coarse security constraints to be imposed upon PowerShell script execution. Execution policies define the restrictions under which PowerShell loads configuration files and runs scripts. The four execution policies are Restricted, AllSigned, RemoteSigned, and Unrestricted.
Support for the use of script signing to verify the identity of a script publisher and to validate the integrity of a published script using digital signatures.
The command-line options are generally whole words, but they can be specified as the minimum number of letters necessary to disambiguate. For example, the option -show-detailed-information could be entered as -s if no other option begins with 's'.
Comprehensive, user-extensible tab completion features. The cmd.exe shell in current versions of Windows can only complete file or directory names, in contrast to the advanced completion in shells such as Bash and zsh.
The ability to assign the output of a command to a variable, which will then be an object or array of objects inspectable in any way desired.