In Windows  10, Microsoft waived the option of an easy PowerShell update and presented a fully overhauled Shell, as demonstrated by the PowerShell environment variable $PSVersionTable, which outputs the version number 5.0.10018.0 . This development is all the more interesting, given that the installation directory still goes by the name v1.0; it will probably keep this name for all time for reasons of compatibility. Existing concepts and commands have been optimized, bugs fixed, and missing parameters added. That accounts for the standard improvements that you would expect on any version change.

However, with each new PowerShell version comes a design highlight. In the current PowerShell on Windows  8.1 and Server  2012  R2, this was the "Desired State Configuration" (DSC), which was designed to make other operating systems such as Unix and Android configurable. What are the fundamental changes that the new PowerShell  5 adds?

Extensions Installed in the Blink of an Eye

This unifying approach is a key feature of PowerShell. However, in version 5, the focus has now shifted to the software infrastructure. Microsoft has revamped the PowerShell module management, in particular for third parties and software package management. Two modules provide the necessary commands: PowerShellGet and OneGet. The similarity between the names is not accidental, and the objectives are very similar. As a universal package manager, OneGet supports centralized management of software packages, their sources, and product versions. In contrast, the PowerShell host's packages are managed using PowerShellGet.

Despite all the advances in PowerShell, you should still not rely exclusively on Microsoft's own extensions. PowerShell modules encapsulate specific commands developed for services or servers. Extensions for VMware (PowerCLI) or Citrix have helped PowerShell assert itself in areas where Microsoft only supplies a part of the IT landscape. Another field of deployment is in extending the current command set. As an example, just look at the popular PowerShell Community Extensions (PSCX) module.

Across all versions of PowerShell, PSCX has offered useful additions, such as the ability to create ZIP archives, voice output, or extended host information, just to name a few. To install the desired extension, though, you first had to find it. On the CodePlex website  [1], users needed to find the right version. Even after downloading and unblocking the file, administrators still had not achieved their objectives. Up to version 2, a complete PowerShell module existed, but it still had to be added to $PSModulePath  – the basic directory of all PowerShell modules.

Providing PSCX is now much easier in version 5: Install-Module pscx. After confirming the untrusted source, the installation simply completes. This is made possible by the convenient approach to managing PowerShell extensions; a new central repository named "PowerShell Gallery"  [2]. Currently, it houses 150 modules deemed to be useful and interesting, and DSC resources are hosted here in addition to PowerShell modules. To take a closer look at a package, enter:

Find-Package -name pscx | select source, links, version | fl

The provider is the newly implemented "chocolatey," and the links contain a reference to codeplex.com (Figure  1). As in OneGet, NuGet is again the driving force behind PowerShellGet, which is a variant on the NuGet Gallery. Just as with OneGet, you can create your own sources and use them as command containers.

Figure 1: PowerShell Community Extensions sources.

This is implemented by the Register-PsRepository cmdlet. If you consider the metaphor of a garden here, the relations are as follows: PowerShell Gallery is the fertilizer that allows PowerShellGet and OneGet to flourish in the OneGet core soil. The soil is delivered by NuGet Provider.

PowerShell Goes Mainstream

Other innovations are also worthy of note, starting with the syntax extension, which sees the scripting language moving closer to object-oriented role models such as C#. Newly added keywords in the language such as class and enum offer users more options for structuring instructions in the development of PS1 scripts.

The scripting engine in PowerShell thus takes a huge step from an object-based scripting language that can only use existing classes to an object-oriented programming (OOP) language. The central construct in the world of OOP is the class keyword, which lets programmers create schematic templates for a more efficient design.

Peek into Packages

In PowerShell  5, script developers can resort to Find-Package for the first time. The properties of an object can be defined by using variables within a class. Methods are class-internal functions. All the interfaces created (i.e., variables and functions) are public; they are usable in the derived object. The scope of a self-defined type is, however, restricted to the module in which it was created.

A simple example illustrates the task of creating and using a class in PowerShell (Listing  1). Instantiating with the static method new() is a little difficult to get used to, but the slightly more consistent

new-Object -typeName NetConfig

is not cleanly implemented at the current time.

01 class NetConfig
02 {
03 #Properties
04 [STRING]$ComputerName = "srv01";
05 [STRING]$IpAddress = "192.168.178.2";
06 [STRING]$DNS = "192.168.178.1";
07 #Methods
08
09         [Void]
10             SetComputerName([STRING]$Name)
11            {
12                  $this.ComputerName = $name;
13            }
14 }
15 $MyObj = [NetConfig]::new();
16 $myObj.ComputerName;
17 $MyObj.SetComputerName("srv02");
18 $myObj.ComputerName;