PowerShell: Module

In order to be found by PowerShell, the module directory must be located in one of the directories that are listed in the environment variable $env:PSModulePath.

A module that is not located in a directory pointed at by $env:PSModulePath can be loaded with the import-module cmdlet.

A handy (automatic) variable when writing PowerShell modules is $PSScriptRoot: when evaluated in a module script (.psm1), its value corresponds to the path of the module directory. Thus, with this value, it is possible to reference other resources that are located in the module directory.

A module consists of up to four optional components:

• A script module (a file with the suffix .psm1)
• A binary module (a file with the suffix .dll)
• A manifest module (a file with the suffix .psd1 that basically contains a key/value hash table)
• A dynamic module (created by the new-module cmdlet)

The base name of the .psm1 and/or .psd1 files need to have the same name as the directory in which they are located. Such files are said to be well-formed modules..

A module manifest is a .psd1 file that contains a hash table and is used to organize and deploy a «solution».

The hash table contains information such as

• contents of the module
• attributes of the module
• names of other modules that the module depends on
• metadata: version number, author, description
• prerequisites required to load the module (for example: PowerShell version, CLR version, other modules)
• processing directives (other scripts, formats and types to process)
• restrictions on exported items (the usual suspects: aliases, functions, variables, cmdlets)
• directory layout
• version numbers
• author data
• etc.

A module manifest file can be created with new-moduleManifest.

Modules may be automatically loaded if they reside in a sub-directory to which one of the components of the environment variable $env:PSModulePath points to.

The behavior of autoloading is controlled by the automatic variable $PSModuleAutoLoadingPreference.

Other modules can be manually imported with the cmdlet import-module.

The import-module has a -prefix parameter. If used, it adds the specified prefix to the respective cmdlet's nouns.

get-module -listAvailable shows available modules.

get-module -all lists the modules thare loaded in the actual PowerShell session along with their exported commands.

get-command -name Microsoft.PowerShell.Management shows the commands in the module Microsoft.PowerShell.Management.

get-command | group-object moduleName | select-object count, name groups commands by their module name.

See the cmdLet noun module.

There are static and dynamic modules.

Dynamic modules exist in memory only, while static modules are stored on disk.

A dynamic module is created with the new-module cmdLet.

A module can be installed for one (the current) user or for all users.

If installed for the current user, the installation directory is $home\Documents\WindowsPowerShell\Modules

If installed for all users, the directory is $env:programFiles\WindowsPowerShell\Modules

The directory $psHome\Modules is reserved for modules that ship with Windows.

Modules that come with a PowerShell installation are

• CimCmdlets
• Microsoft.PowerShell.Archive
• Microsoft.PowerShell.Core
• Microsoft.PowerShell.Diagnostics
• Microsoft.PowerShell.Host
• Microsoft.PowerShell.Management
• Microsoft.PowerShell.Security
• Microsoft.PowerShell.Utility
• Microsoft.WSMan.Management
• PackageManagement
• PowerShellGet
• PSDesiredStateConfiguration
• PSDiagnostics
• PSReadline

Modules cannot be loaded or executed if the execution policy is set to restricted.

get-installedModule returns a list of modules that are installed on a computer.

Access module-private variables with the call operator (&).

Setting a module's property LogPipelineExecutionDetails to $true to log module events.

The using module statement.

Some (mostly simple or lightweight) PowerShell modules I have written.