Introducing modules

Modules were introduced with the release of PowerShell version 2.0. A module is a packaged set of commands (binary commands, functions, and aliases) that includes any required supporting content; modules often include help content.

PowerShell 5.1 introduced support for classes written in PowerShell. These are explored in Chapter 19, Classes and Enumerations, but while support is present these are rarely directly user-accessible.

Modules tend to target a specific system or focus on a small set of related operations. For example, the Microsoft.PowerShell.Archive module contains a small number of commands for interacting with ZIP files.

The modules available on a system can be discovered using the Get-Module command.

The Get-Module command

Get-Module is used to find the modules either in the current PowerShell session or available on the current system.

PowerShell itself comes with several built-in modules, including PowerShellGet, ThreadJob, PSReadLine, and the commands in the...

Finding and installing modules

PowerShell includes a module named PowerShellGet, which can be used to register repositories and search for and install modules.

By default, PowerShellGet searches the PowerShell Gallery.

What is the PowerShell Gallery?

The PowerShell Gallery is a Microsoft-run repository and distribution platform for PowerShell scripts and modules written by Microsoft or other users.

The PowerShell Gallery has parallels in other scripting languages, as shown in the following examples:

• Perl has cpan.org.
• Python has PyPI.
• Ruby has RubyGems.

Support for the gallery is included by default in PowerShell 5 and above. For Windows PowerShell 3 and 4, PowerShellGet must be installed as described in Microsoft Learn:

https://learn.microsoft.com/en-us/powershell/gallery/powershellget/install-on-older-systems.

The PowerShell Gallery may be searched using https://www.powershellgallery.com, as shown in the following screenshot:

Figure 2.2: Searching the PowerShell Gallery...

Microsoft.PowerShell.PSResourceGet

PowerShellGet 2 (for example, PowerShellGet 2.2.4.1) implements the Install-Module, Update-Module, and Save-Module module commands demonstrated at the beginning of this chapter.

Microsoft.PowerShell.PSResourceGet (PSResourceGet), formerly PowerShellGet 3, hopes to replace PowerShellGet version 2 installations. One of the key features is that this new version does not depend on the PackageManagement module, allowing a simpler installation process, and avoiding the need to bootstrap the NuGet provider, making upgrading the module simpler.

The preview version also uses new command names, completely divorcing it from the previous implementations of PowerShellGet. The change in command names means the new version can safely be installed alongside any existing version.

PSResourceGet is included with the PowerShell 7.4 installation.

If not installed, PSResourceGet can be installed as follows:

Install-Module Microsoft.PowerShell.PSResourceGet

Once installed, the PowerShell...

PowerShell repositories

Each of the examples from the previous section uses the PowerShell Gallery as a source for installing modules. This is an important resource, but in a business setting, it may be desirable to restrict access to the gallery. Instead, an internal repository that holds curated or internally developed content may be implemented to share content.

Creating an SMB repository

An SMB file share is a simple way to share PowerShell content. A file share may be registered as a repository as follows:

$params = @{
    Name               = 'Internal'
    SourceLocation     = '\\server\share\directory'
    InstallationPolicy = 'Trusted'
}
Register-PSRepository @params

Existing modules can be published to the repository using the Publish-Module command. For example, if the module Pester 5.0.2 is installed, it may be published to the newly created internal repository:

$params = @{
    Name            = 'pester'
    RequiredVersion = &apos...

About snap-ins

Snap-ins, and the commands for interacting with snap-ins, are only available in Windows PowerShell; they are not present in PowerShell 7 and the commands used below will not work.

A snap-in is the predecessor to a module. It was the mechanism available to extend the set of commands in PowerShell 1 and was deprecated with the release of PowerShell 2. Unfortunately, a small number of organizations persist in offering PowerShell commands via a snap-in.

The list of installed snap-ins may be viewed using the following command:

Get-PSSnapIn -Registered

If the Registered parameter is excluded, Get-PSSnapIn will show the snap-ins that have been imported into the current PowerShell session.

PowerShell does not automatically load commands from a snap-in. All snap-ins must be explicitly imported using the Add-PSSnapIn command:

Add-PSSnapIn WDeploySnapin3.0

Once a snap-in has been installed (registered) and added, Get-Command can be used to list the commands as if the snap-in were a module...

Summary

Modules are a vital part of PowerShell. Modules allow users to extend the commands available within PowerShell, allowing PowerShell to work with many different systems from many different vendors.

The commands explored in this chapter have demonstrated how to discover and use locally available modules along with the commands each module contains. The PowerShell Gallery has been introduced as a public repository of modules, extending PowerShell further still.

PowerShellGet has been a feature of PowerShell since PowerShell 3. With the release of PowerShellGet 3 on the horizon, we demonstrated its new commands and filtering capabilities.

SMB- and NuGet-based repositories were briefly introduced for those looking to establish private repositories for use within an organization. This allows administrators to create private repositories with curated content, reducing exposure to unknown modules.

Snap-ins, an artifact of PowerShell 1 that is limited to Windows PowerShell, were very briefly...