Modules were introduced with the release of PowerShell version 2.0. Modules represented a significant step forward over snap-ins. Unlike snap-ins, modules do not have to be formally installed or registered for use with PowerShell.

It is most common to find a module that targets a specific system or focuses on a small set of related operations. For example, the Microsoft.PowerShell.LocalAccounts module contains commands for interacting with the local account database (users and groups).

A module may be binary, script, dynamic, or manifest:

• Binary modules: These are written in a language such as C# or VB.NET, and then compiled into a dynamic-link library (DLL).
• Script modules: These are a collection of functions written in the PowerShell language. The commands typically reside in a script module file (PSM1).

• Dynamic modules: These are created using the New-Module command and exists in memory only. The following command creates a very simple dynamic module that adds the Get-Number command:

New-Module -Name TestModule -ScriptBlock { 
    function Get-Number { return 1 } 
}

• Manifest modules: These combines different items to make a single consistent module. For example, a manifest may be used to create a single module out of a DLL containing cmdlets and a script containing functions, and Microsoft.PowerShell.Utility is a manifest module that combines a binary and script module.

A manifest module may also be used to build commands based on WMI classes. The cmdlets-over-objects feature was added with PowerShell 3, an XML file with a cdxml extension (cmdlet definition XML). For example, the Defender module creates commands based on WMI classes in the ROOT/Microsoft/Windows/Defender namespace.

The cmdlets-over-objects feature is explored by Richard Siddaway in a series of blog posts on the Scripting Guy site. The first of these is found here: https://blogs.technet.microsoft.com/heyscriptingguy/2015/02/03/registry-cmdlets-first-steps-with-cdxml/.

The module manifest file serves a number of purposes, including the following:

• Describing the files that should be loaded (such as a script module file, a binary library, and a cmdlet definition XML file)
• Listing any dependencies the module may have (such as other modules, .NET libraries, or other DLL files)
• Listing the commands that should be exported (as in, made available to the end user)
• Recording information about the author or the project

When loading a module with a manifest, PowerShell will try and load any listed dependencies. If a module fails to load because of a dependency, the commands written as part of the module will not be imported.