Innovations in PowerShell 5
Upshift
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.
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.
Listing 1
Creating and Using Classes
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;
Buy this article as PDF
(incl. VAT)